• Entretien avec le créateur du Bottin des jeux linux
    Le site « Le Bottin des jeux linux » recense les jeux vidéo sous Linux. Il a été créé en 2007 par Serge Le Tyrant. Celui-ci, en voulant mettre un peu d’ordre dans sa base de données de jeux, a fini par en effectuer la refonte complète. Après un travail important de mise en forme et de mi... (Lire l'article)
  • Conférences audio et vidéo
    Retrouvez les conférences données lors des Ubuntu party ou d'autres événements, ainsi que les interviews par OxyRadio. (Lire l'article)
  • Entretien avec Aviv de l'équipe de Wildfire Games
    Pour ceux qui ne le savent pas encore, 0 A.D. est un jeu de stratégie en temps réel de guerre antique, développé par l'équipe de Wildfire Games, et qui a été complètement libéré en 2009. (Lire l'article)
  • Entretien avec Quentin Bolsée, le développeur de ColorCube
    Très récemment, Quentin a annoncé la disponibilité de son jeu : ColorCube, un jeu basé sur le Blender Game Engine. Entretien d'un jeune et talentueux développeur. (Lire l'article)
  • Pourquoi devriez-vous utiliser OpenGL et non DirectX ?
    Il y a quelques jours, sur le blog de Wolfire Games, est apparu un intéressant point de vue sur les raisons d'utiliser OpenGL. L'article étant fort intéressant, nous vous l'avons traduit, pour qu'il profite au plus grand nombre. (Lire l'article)
  • Entretien avec l'équipe des Landes Eternelles
    Suite à la sortie, il y a un peu plus d'un mois, de la nouvelle version du client de Landes Eternelles, un mmorpg multi plateforme, nous avons voulu interroger Ackak & Nati, deux des administrateurs du serveur. (Lire l'article)
  • Entretien avec l'équipe de Smokin'Guns
    Si vous nous lisez régulièrement, vous savez que toute l'équipe de jeuxlinux.fr est fan de Smokin'Guns. Plusieurs questions nous trotté dans la tête concernant la suite de ce jeu, et ce n'est autre que ReD NeCKersoN et Téquila, les deux piliers de l'équipe, qui vont nous donner les réponses. (Lire l'article)
  • Créer une course pour Tux Racer
    La création de nouvelles pistes dans les Tux Racer libres est une chose qui a été vraiment bien pensé. Même si elle ne permet pas de creuser des sous-terrains ou de régler l'orientation des objets par exemple, elle vous permettra de modéliser assez facilement et plutôt rapidement des courses... (Lire l'article)
  • Entretien avec Frictional Games
    Ce mois-ci, les développeurs de Frictional Games, à l'origine de la série des Penumbra, nous parlent de leurs jeux, de leur modèle de développement ainsi que de leur projets futurs. La série des Penumbra contient des jeux d'horreur d'une excellente qualité vous plongeant dans un univers noir... (Lire l'article)
  • Open Transport Tycoon
    Les jeux de gestion sont rares sous linux, trop rares au point qu'il n'existe même pas de catégorie gestion sur jeuxlinux. Ce genre de jeu demande de la profondeur et un sens du détail hors du commun. (Lire l'article)

Le son sous Linux


Auteur(s) de l'article : lululaglue - Date de parution : 27 mai 2006

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é.



Introduction

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*



Écouter plusieurs sons en même temps

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.

Les applications qui utilisent le son

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.