Discussion :

[meynaf]

Bonjour,


J'ai réussi à faire jouer à xaudio2 ce que je voulais qu'il joue. En tous cas pour un test simple.
Ce que je veux, c'est du temps réel, pas jouer un wav avec 4 secondes d'avance.
Du coup il faut appeler SubmitSourceBuffer un paquet de fois par seconde, en envoyant peu de données en une fois, sinon l'utilisateur se demandera pourquoi le son est décalé de l'image...

Mais dès que je descends en-dessous d'une demi-seconde (24000 samples en 48000hz), il commence à y avoir des "trous" dans l'audio.
Bien sûr plus on descend et moins ils sont espacés. Avec une taille suffisamment basse - mais théoriquement tout à fait valide - c'est carrément l'horreur.

Une taille pareille rend xaudio2 totalement inutilisable pour ce que je voulais en faire. "Low latency" mon oeil, pour ne pas dire mon autre chose.
Donc si je n'ai pas de solution je suis coincé, et, peut-être, obligé de tout recommencer. Par exemple utiliser wasapi, mais c'est incomparablement plus compliqué et je n'ai aucun exemple que je puisse utiliser comme base.

Ma méthode actuelle est de lancer un thread qui va attendre qu'on lui fournisse quelque chose et jouer le(s) son(s) demandé(s) jusqu'à la fin ou indéfiniment si ça boucle.
On remplit simplement une structure, on la lui passe et il se débrouille avec.
Je dois faire le mixage "à la main" parce qu'xaudio2 ne fournit pas les fonctionnalités requises - ou alors j'ai pas trouvé.
Pour le moment, une seule voie - avec un mixage rapide et nase qui plus est - suffit à échouer misérablement.

Mais peut-être ai-je simplement foiré quelque part ?
Y a-t-il des pièges dans lesquels ne pas tomber ?
Une méthode "classique" qui permette de s'en sortir en pareil cas ?

Note : je peux poster le code ici s'il le faut mais >600 lignes c'est pas idéal.

[LittleWhite]

Bonjour,

Autant que j'ai pu le comprendre, il semble que vous utilisez un thread, qui reçoit les données audio d'autre part. Qu'est ce qui vous dit que votre thread (ou la transmission des données) se fait exactement au moment où le voulez. Généralement, l'OS peut prendre du temps à réveiller tel ou tel thread. Certes le décalage n'est pas "énorme", mais pour de l'audio, c'est perceptible immédiatement.

[meynaf]

Certes le décalage existe, mais il est de l'ordre de 16ms ou un truc dans le genre.
Or ici j'en suis à une demi-seconde, soit 500ms : je sais que windows n'est pas un système temps réel, mais là il exagère !
Du point de vue de la vidéo, c'est plus de 70 frames !
On n'est clairement pas dans une situation où c'est l'ordonnanceur qui coince.

De plus, le thread principal lit depuis le fichier et envoie les données par pavé de 4 secondes...
Ce n'est pas du tout l'utilisation typique qui est prévue, mais au moins ça me simplifie mon affaire dans un premier temps.
Il va de soi que les trous sont bien plus fréquents que ça, sinon j'aurais compris d'où ça venait.