Vu que la lib SDL est un appli assez bas niveau pour faire du son (basiquement on donne un wav à lire, et on fait le ping-pong avec 2 buffer audio, l'un se rempli, l'autre se lit)
Oui, c'est du très haut niveau çà en appli son.
Le haut niveau en fichier son c'est echo "fichier.wav" > /dev/macarte.
Pour te donner une idée voilà comment fonctionne la SDL avec le support Alsa dans Linux quand elle est en mode exclusif (ie aucune autre appli ne joue de sons) sur une carte en prise direct (ie pas de surcouche d'émulation dans alsa driver):
Appli -> SDL -> Alsalib -> Alsa -> Alsa driver
En vrai ca donne souvent çà :
Appli -> SDL -> Alsalib -> Alsa -> Alsa driver HDA PCM interface -> Alsa driver
Être bas niveau ca revient à discuter directement avec le matériel, voire à discuter avec les HControl/PCM/AC97 et autre interface à la con du driver Alsa (à la con parcequ'instables et non/mal documentés)
Tout ce que tu décris se fait en SDL
La SDL va permettre de mixer du son avec un autre appli qui parle avec GStreamer ? La SDL va empêcher pulseaudio de chopper une carte son ne mode exclusif ? La SDL va permettre à mon appli de partager un device avec trois autres applis qui ont des fréquences de rendu différentes ?
La SDL est une bibliothèque destiné au userland, pas un module noyau. Tout ce que peut faire la SDL c'est de cracher du son dans une interface. Après que ce son soit super bien foutu, soit le résultat du mixage de son de pleins de sons etc. on s'en fout. SDL c'est une instance par appli et par user.
Pour OpenAl, je pourrai pas donner plus de précision, mais vu comment râlent les joueurs lorsque les sons ne sont pas synchronisés je serai surpris que ça ne le permettes pas
Bine sur que dans la bibliothèque OpenAL il y a des fonctions qui permettent de synchroniser le son et l'image au sein de l'appli. Mais une fois d eplus on est mono appli, mono user. Y-a-t-il dans OpenAL une fonction qui permette de dialoguer avec le scheduler pour s'assurer que les sons seront effectivement synchronisés lors du rendu : non. OpenAL est userland aussi, il crache du son dans un device et c'est tout.
Je sais pas moi le premier truc que je ferai avant de tenter de coller l'image au son, c'est réduire la consommation démesuré de CPU; généralement la synchro pose moins de problème après :)
Perdu faut faire le contraire, il faut consommer un maximum de CPU, charger la mule le plus possible pour s'assurer que
a) les buffers sont pleins le plus longtemps possible
b) le scheduler se rende compte que tu es très consommateur de ressources et te passe dans un mode ou il t'alloue de grande tranche de temps de loin en loin plutôt que pleins de petites tranches de son. C'est ce qui garanti la cohésion image/son (entre autres).
De toute façon quand tes buffers sont pleins, tu rend la main - ta consommation de CPU au final reste la même.
[^] # Re: Cela dépend des cas...
Posté par Jerome Herman . En réponse au journal Linux ou POSIX ?. Évalué à 3.
Oui, c'est du très haut niveau çà en appli son.
Le haut niveau en fichier son c'est echo "fichier.wav" > /dev/macarte.
Pour te donner une idée voilà comment fonctionne la SDL avec le support Alsa dans Linux quand elle est en mode exclusif (ie aucune autre appli ne joue de sons) sur une carte en prise direct (ie pas de surcouche d'émulation dans alsa driver):
Appli -> SDL -> Alsalib -> Alsa -> Alsa driver
En vrai ca donne souvent çà :
Appli -> SDL -> Alsalib -> Alsa -> Alsa driver HDA PCM interface -> Alsa driver
Être bas niveau ca revient à discuter directement avec le matériel, voire à discuter avec les HControl/PCM/AC97 et autre interface à la con du driver Alsa (à la con parcequ'instables et non/mal documentés)
Tout ce que tu décris se fait en SDL
La SDL va permettre de mixer du son avec un autre appli qui parle avec GStreamer ? La SDL va empêcher pulseaudio de chopper une carte son ne mode exclusif ? La SDL va permettre à mon appli de partager un device avec trois autres applis qui ont des fréquences de rendu différentes ?
La SDL est une bibliothèque destiné au userland, pas un module noyau. Tout ce que peut faire la SDL c'est de cracher du son dans une interface. Après que ce son soit super bien foutu, soit le résultat du mixage de son de pleins de sons etc. on s'en fout. SDL c'est une instance par appli et par user.
Pour OpenAl, je pourrai pas donner plus de précision, mais vu comment râlent les joueurs lorsque les sons ne sont pas synchronisés je serai surpris que ça ne le permettes pas
Bine sur que dans la bibliothèque OpenAL il y a des fonctions qui permettent de synchroniser le son et l'image au sein de l'appli. Mais une fois d eplus on est mono appli, mono user. Y-a-t-il dans OpenAL une fonction qui permette de dialoguer avec le scheduler pour s'assurer que les sons seront effectivement synchronisés lors du rendu : non. OpenAL est userland aussi, il crache du son dans un device et c'est tout.
Je sais pas moi le premier truc que je ferai avant de tenter de coller l'image au son, c'est réduire la consommation démesuré de CPU; généralement la synchro pose moins de problème après :)
Perdu faut faire le contraire, il faut consommer un maximum de CPU, charger la mule le plus possible pour s'assurer que
a) les buffers sont pleins le plus longtemps possible
b) le scheduler se rende compte que tu es très consommateur de ressources et te passe dans un mode ou il t'alloue de grande tranche de temps de loin en loin plutôt que pleins de petites tranches de son. C'est ce qui garanti la cohésion image/son (entre autres).
De toute façon quand tes buffers sont pleins, tu rend la main - ta consommation de CPU au final reste la même.