Discussion :

[ICR5_68]

Bonjour,

Je me permet de poser cette question ici car je n'ai trouvé aucun réponse claire et concise à ma question.

En fait je ne comprend pas comment est géré l'acquisition des données audio par le driver audio ... je m'explique, admettons le code suivant dans le même processus ( fd étant un descripteur de fichier du style /dev/dsp sous Linux).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
 
...
read(fd, buf, size);
 
...
 
process(buf, size);
 
...

Est-ce que l'on "perd des données" durant le temps de traitement de la fonction process() ? Ou est-ce que le drivers continue de mémoriser "en interne" les échantillons de l'entrée audio ? Le cas échéant il doit bien y avoir une limite de taille non ?

J'espère avoir été assez clair, sinon n'hésitez pas à me demander de mieux expliquer mon problème.

Merci pour vos éventuelles réponses.

[pfeuh]

Salut,

Je vois à peu près comment ça se passe sur la sortie, alors je suppose que sur l'entrée c'est la même chose... Je suis sous Windows, les autres systèmes sont peut-être différents. Sur la sortie, on envoie un paquet à la carte son qui possède son propre buffer d'entrée. une interruption levée par la carte son indique que son buffer est presque vide et un callback est chargé d'envoyer le prochain paquet. C'est tout le problème du "temps de latence" qui fait que les musiciens haïssent leur PC, car on a beau écrire quoi que ce soit dans le paquet, il ne sera pas transmis immédiatemment.

En entrée, je suppose que la carte son échantillonne son bus audio et bufférise ses données. Elle doit envoyer cycliquement une interruption du genre "mon buffer est quasi-plein" pour qu'un callback récupère les données. Si quelqu'un en sait plus, je suis sûr que ça intéressera beaucoup de monde.

[ICR5_68]

Merci de ta réponse.

C'est bien ce que je pensais, mais dans mon cas, je pense perdre des données le temps d'exécuter process() ...

A moins de mettre le read() dans un autre thread et de libérer un sémaphore lorsque la lecture est terminée ?

[pfeuh]

C'est peut-être le problème classique: Pour diminuer la latence, on diminue la taille du buffer. Ca part d'un bon sentiment, ça marche dans 95% des cas, mais il suffit que l'OS soit un peu chargé (genre plein d'accès disque ou autres) et c'est perdu... Je ne sais pas comment tu développes, mais je te conseille une librairie spécialisée comme SDL ou FMOD, qui encapsulent ça très bien et qui n'ont plus à faire leurs preuves. En plus elles sont multiplateforme (pour fmod, je ne suis pas sûr). Les threads et les callbacks sont encapsulés, tu peux te concentrer ainsi sur l'essentiel.

[LittleWhite]

C'est peut-être le problème classique: Pour diminuer la latence, on diminue la taille du buffer. Ca part d'un bon sentiment, ça marche dans 95% des cas, mais il suffit que l'OS soit un peu chargé (genre plein d'accès disque ou autres) et c'est perdu... Je ne sais pas comment tu développes, mais je te conseille une librairie spécialisée comme SDL ou FMOD, qui encapsulent ça très bien et qui n'ont plus à faire leurs preuves. En plus elles sont multiplateforme (pour fmod, je ne suis pas sûr). Les threads et les callbacks sont encapsulés, tu peux te concentrer ainsi sur l'essentiel.

Je confirme FMOD est très multiplateforme ( les consoles sont aussi supportées )