Ca vous est surrement arrivé de vouloir lançer votre jeux préféré tout en continuant d’écouter vos mp3. Et la problème ! aucun son dans le jeu ??? Pour éviter ce genre de problème, il faut comprendre comment fonctionne votre système, et il faut avoué que c’est un peu compliqué.
Le coeur de votre système est constitué d’un noyau Linux. C’est lui qui va s’occuper de votre matériel, notamment votre carte son, grâce au pilote approprié. Cependant, déjà là, ça commence mal car Linux peut s’occuper de votre carte son selon deux méthodes distinctes : OSS et Alsa.
OSS
Anciennement (c’est-à-dire jusqu’au noyau 2.4), la partie de Linux qui permettait une gestion de votre carte son était appélée Open Sound System, OSS. Beaucoup de pilotes ont été développés pour OSS.
De même, beaucoup d’applications utilisent encore OSS pour utiliser la carte son. En effet, ça fonctionnait pas trop mal...
Pour savoir quels sont les programmes qui sont en train d’utiliser OSS, il suffit de taper :
lsof /dev/dsp
ALSA
OSS n’étant techniquement pas parfait, un remplaçant a été trouvé. Ce remplaçant est ALSA, pour Advanced Linux Sound Architecture [1]. Les programmes utilisant du son doivent donc être réécrits pour pouvoir utiliser ALSA à la place de OSS. (c’est pourquoi xmms a un plugin OSS et un plugin ALSA par exemple).
Cependant, afin que les anciennes applications continuent à fonctionner, il existe dans ALSA une couche de compatibilité qui permet aux applications OSS de croire qu’elles utilisent OSS au lieu de ALSA. Le greffon Flash de Macromedia, par exemple, ne connait pas ALSA et continue d’utiliser OSS.
Notons qu’il est aussi nécessaire de réécrire tous les pilotes de carte son [2], connu aussi sous le nom de "module". Ce module est normalement lancé automatiquement à chaque démarrage. La commande lsmod permet d’afficher la liste des modules chargés sur votre système. Ceux qui concernent ALSA ont un nom commençant par "snd".
Pour savoir quels programmes utilisent pour le moment alsa :
lsof /dev/snd/pcm*
Généralement, une carte son ne dispose que d’une seule sortie. D’où, le noyau Linux ne sort qu’un seul son à la fois. Si on lui en demande plusieurs en même temps, le premier passera et pour les autres apparaîtra le message "device busy", qui signifie que le périphérique est occupé.
L’oreille humaine étant capable de différencier plusieurs sons mélangés, il faut donc mélanger -mixer- les différents sons avant de les envoyer au noyau Linux. Pour cela, il existe plusieurs solutions, dont nous citerons :
ESD
ESD, Enlightened Sound Daemon, est un programme au départ conçu pour Gnome qui mélange les sons et les envoie ensuite à OSS ou ALSA. Le problème c’est que quand ESD est lancé, seul lui occupe la carte son, et donc tous les programmes qui n’utilisent pas ESD sont muets. On va donc dire à ESD de se lancer uniquement quand on a besoin de lui et de se couper après X secondes d’inactivité.
La config est visible dans /etc/esound/esd.conf : auto_spawn=1 (lancement automatique) et, dans spawn_options : -terminate -as 2 (arrêt après 2 secondes d’inactivité).
Le gros problème d’ESD, outre que tous les programmes ne l’utilisent pas, est qu’il introduit un temps de latence. Pour résoudre ça, un remplaçant théoriquement bien meilleur est en préparation : polypaudio.
Notons que ESD n’a pas que des désavantages : il permet, par exemple, d’écouter de la musique à travers un réseau. On joue la musique sur un ordinateur et le son sort sur un autre.
Par défaut, ESD utilise OSS. Mais l’installation de la libesd-alsa0 lui permet d’utiliser ALSA.
Arts
Arts, c’est exactement comme ESD mais pour KDE au lieu de Gnome.
Dmix
Dmix est en fait l’approche la plus logique. Contrairement aux deux premiers, ce n’est plus un programme externe mais directement ALSA qui va s’occuper du mixage, profitant des capacités de mixage hardware des cartes qui en possède. Pour activer Dmix, il suffit de créer un fichier /etc/asound.conf comme expliqué sur différents forums.
Dmix n’est pas toujours activé par défaut car il introduit des plantages avec certaines cartes son. Soyez prudents.
Tout ce que nous avons vu concerne l’accès direct à la carte son. Cependant, dans la majorité des cas, les sons sont stockés sous forme de fichiers, le tout dans différents formats : ogg Vorbis, mp3, ....
Il faut donc les décoder et c’est ce que fait une application comme XMMS : elle décode un fichier suivant le format, le transforme en son et l’envoie à la carte son selon la sortie choisie.
À chaque fois qu’on crée un nouveau lecteur multimédia, on doit implémentation le décodage du mp3, ogg, etc... C’est pour régler ce problème que de grands hackers ont créé :
GStreamer
GStreamer est un "framework". C’est en fait une application comme une autre qui accède à la carte son. Il est possible, en ligne de commande, de lire des fichiers audio avec gstreamer. Par exemple :
gst-launch gnomevfssrc location=musique.ogg ! vorbisfile ! esdsink
(où musique.ogg est un fichier.ogg) [3]
Grâce à cette architecture, d’autres programmes peuvent utiliser GStreamer et ne doivent plus implémenter décodage des fichiers. Il suffit de dire "GStreamer lit moi ça !" et GStreamer le lit. "GStreamer, encode moi ça !" et GStreamer l’encode. Le paradis quoi !
Rhythmbox, Sound-Juicer et Totem, entre autres, utilisent GStreamer.
Le sélecteur de systèmes mutlimédia (dans les préférences où gstreamer-properties dans une console), permet de choisir quelle sortie on veut que les applications GStreamer utilisent : OSS, Alsa, ESD.
Ainsi, si dans ce sélecteur on déclare vouloir utiliser ESD, Rhythmbox et Totem utiliseront par conséquent ESD. Xmms, par contre, ne sera pas afecté vu qu’il n’utilise pas GStreamer. Logique...
GStreamer est très modulaire, et il est très facile de rajouter un plugin pour lire un format particulier. Par défaut, GStreamer ne possède pas le support pour lire des mp3. C’est peut-être pourquoi votre xmms lit des mp3 mais pas Totem ou Rhythmbox. Il suffit donc d’installer le plugin GStreamer adéquat : gstreamer0.8-plugins, gstreamer0.8-plugins-multiverse et gstreamer0.8-ffmpeg [4]
Cet article est une modification d’un article de « ploum », paru sur son blog, avec son autorisation.
_
[1] Comme toujours, ALSA est théoriquement bien meilleur que OSS. En pratique, ça n’est vrai que quand il fonctionne correctement...
[2] Et c’est là que le bât blesse avec ALSA : beaucoup de pilote sont très mal écrit et personne ne souhaite les corriger. Ceci explique pourquoi, sur certaines carte son, on a une meilleure qualité d’écoute en passant par l’émulation OSS d’ALSA que par ALSA directement.
[3] On remarque qu’ici on prend le fichier musique.ogg depuis le système de fichier de gnome, on le décode via le décodeur Vorbis et on envoie le résultat vers ESD. Cette structure permet toutes les fantaisies comme, par exemple, convertir un mp3 en ogg. Plus d’infos.
[4] Les noms de ces paquets peuvent changer d’une distributions à l’autre.