moteur audio - C++ - Programmation
Marsh Posté le 14-03-2007 à 18:58:48
Hésite pas a augmenter ton buffer_size, je le fixera à 65536.
De plus, je ferais un sleep entre chaque filling de buffer tant que celui ci n'a pas son flag à WHDR_DONE.
Marsh Posté le 14-03-2007 à 20:53:39
merci je vais essayer
65536 c'est super long comme retatd c'est plus vraiment du temps reel Y' a pas mieux comme solution ?
karlkox a écrit : Hésite pas a augmenter ton buffer_size, je le fixera à 65536. |
Marsh Posté le 14-03-2007 à 21:57:01
Déjà, ce que tu peux faire, c'est un tableau de WAVEHDR, dans ton thread, tu incrémenteras une variable (à locker) qui indiquera le buffer en cours de traitement, tu pourras ainsi pointer sur le bon WAVEHDR, tu l'écrit sur le device puis tu attends que son flag soit sur WHDR_DONE.
C'est ce que fait la SDL (je me suis basé la dessus) et ça a réglé le même problème que le tient que j'ai eu. (mais j'ai du augmenter le buffer size, driver creative inside ...)
Marsh Posté le 14-03-2007 à 22:10:27
C'est quoi le probleme avec les drivers creative rapport a la latence?
Marsh Posté le 14-03-2007 à 22:31:40
Disons que Creative fait du bon matos mais que niveau ingénierie logiciel, ils peuvent mieux faire, ce n'est pas à la hauteur du matos qu'ils font en tout cas.
Marsh Posté le 14-03-2007 à 22:33:45
bon bah moi en attendant je reécris comme tu as indiqué et je mettrais le nouveau code ici.
Marsh Posté le 14-03-2007 à 22:41:39
J'aurais aime une reponse plus precise, car je fais de l'acquisition audio sur une carte creative avec une precision temporelle de l'ordre de la milliseconde avec un buffer de 96 echantillons, et ca marche plutot pas mal. Quelles sont les tares cachees du driver ?
Marsh Posté le 14-03-2007 à 22:56:31
J'ai une Creative moi aussi et je tape dans du 2ms sans problème, ce n'est pas forcément un problème de latence mais un problème plus global : stabilité, grésillement possible, impossibilité de reprogrammer le spu sans passer par un sdk (qui n'est fournis que si on fait partis d'une grosse boite de dev).
Marsh Posté le 14-03-2007 à 23:00:01
oui, maintenant que tu le dis, une fois sur dix environ, j'ai une acquisition qui foire, et a place du joli bip de reference que je suis cense enregistrer, j'ai des gresillements. Ca viendrait donc du driver ?
Marsh Posté le 14-03-2007 à 23:11:15
Le problème de grésillement est assez récurant chez Creative malheureusement SAUF sur la X-Fi Elite Pro (que j'ai).
Marsh Posté le 16-03-2007 à 21:41:57
Bonjour
Moi je ne comprends pas tres bien comment introduire CreateEvent, WaitForSingleObject, SetEvent, WHDR_DONE etc... dans mon code.
Quelqu'un peut il m'aider svp ?
merci
Marsh Posté le 16-03-2007 à 23:31:55
est ce que j'ai le droit de traiter le MM_WIM_DATA et le MM_WOM_DONE par le meme thread ?
Marsh Posté le 16-03-2007 à 23:37:24
le directsound serait pas moins pire que le WaveOut ?
parceque quand j'entends parler de grésillements, et que je vois que c'est une approche par message, j'ai peur
Marsh Posté le 17-03-2007 à 07:16:21
bjone a écrit : le directsound serait pas moins pire que le WaveOut ? |
Y'a aussi possibilite d'utiliser des vrais callbacks dans WaveOut
Marsh Posté le 17-03-2007 à 07:18:11
Ah bon ? ca peut etre interessant que tu modifies mon code pour montrer comment
merci
Marsh Posté le 17-03-2007 à 07:25:40
La fonction waveOutOpen accepte comme dernier parametre
CALLBACK_FUNCTION au lieu de CALLBACK_THREAD. cf la msdn
Marsh Posté le 17-03-2007 à 07:28:05
oui je connais CALLBACK_FUNCTION mais le probleme est d'introduire et gerer le partage des ressources avec CreateEvent, WaitForSingleObject, SetEvent, WHDR_DONE etc.
Marsh Posté le 17-03-2007 à 11:26:45
Je sais pas si c'est adéquat, mais il y a moyen de trouver des drivers ASIO pour les creatives sur le net...
http://forum.hardware.fr/hfr/Video [...] 8445_1.htm
Marsh Posté le 17-03-2007 à 13:54:13
gabuzomeuh2 a écrit : est ce que j'ai le droit de traiter le MM_WIM_DATA et le MM_WOM_DONE par le meme thread ? |
Oui bien sûr, aucun problème.
bjone>ce n'est pas tant un problème de driver de sortie son mais un problème d'implémentation de celui ci, il suffit de faire abstraction du driver avant de s'attaquer vraiment à la partie API sonore (dsound, winmm, oal ...).
Perso, j'utilise les threads et aucun problème, ça m'a aussi permis de ne plus avoir ce problème de grésillement qui est dû à une mauvaise synchronisation entre la notification windows et le buffer à remplir.
breizhbugs>les pilotes ASIO font partis intégrante des pilotes. (CTASIO)
Marsh Posté le 25-03-2007 à 05:35:05
Voila j'ai tout réecrit. On dirait que ca marche.
Tu peux me dire ce que tu en penses KarLKox ?
Code :
|
Marsh Posté le 25-03-2007 à 17:59:14
Pourquoi diable avoir mis de l'assembleur la dedans? Ensuite cherche du cote de l'instruction "movsb" et meme "rep movsb", ce que tu implementes via une boucle, le processeur sait deja le faire :-)
Et pour finir, un simple memcpy aurait fait l'affaire non?
Marsh Posté le 25-03-2007 à 21:05:02
Ca me parait déjà plus clean et efficient, bon pour la boucle asm, en effet, un memcpy est aussi rapide donc pas besoin de passer par la, à la limite en simd (sse/sse2), histoire de copier plus de bloc par cycle.
Marsh Posté le 25-03-2007 à 21:59:59
En effet ca a l'air plus efficient et il n'y a plus d'interruption de processus quand la Fenetre est reduite ou restaurée.
Malgré tout, on dirait que le InThreadPRoc et OutThreadProc finissent par se marcher dessus au bout d'un cerain nombre de tours. Qqn a une solution ?
Marsh Posté le 25-03-2007 à 22:01:35
J'aimerai mettre le traitement de WIM_DATA et WOM_DONE dans le mm thread.
Marsh Posté le 14-03-2007 à 15:07:19
bonjour
j'ai ecrit un moteur audio temps reel pour faire du traitement de signal en direct. J'ai ajouté un SetThreadPriority pour chaque procédure In et Out mais ca ne change rien, quand la fenêtre est réduite ou restaurée, il y a une courte interruption du processus. Quelqu'un a une piste ?