Aller au contenu

[Tuto][Initié] ALSA, gestion du son sous linux


tuXXX

Messages recommandés

  • Réponses 145
  • Créé
  • Dernière réponse

:chinois:1) Introduction

La gestion du son est primordiale pour une bonne expérience multimédia, quel que soit l'OS.

Sous Linux, le système de gestion des flux sonores était auparavant OSS (Open Sound System).

Mais il avait certaines limitations (performances non optimales, difficultés de configuration, etc...)

C'est dans ce contexte qu'a été créé ALSA (pour Advanced Linux Sound Architecture). ALSA est composé de 4 composants principaux :

  • le support dans le noyau.
  • les drivers.
  • la librairie d'interfaçage permettant la communication entre les programmes et le noyau.
  • quelques applications permettant de gérer la configuration et de faire un peu de diagnostic.

Je vais par la suite décrire chacun de ces composants plus précisément, puis montrer comment configurer un système en utilisant ALSA.

Quelques liens relatifs :

http://www.alsa-project.org : site officiel du projet

http://www.alsa-project.org/alsa-doc : liste de l'état du support des différentes cartes son

http://alsa.opensrc.org : wiki officiel, contient vraiment beaucoup d'infos

Lien vers le commentaire
Partager sur d’autres sites

:chinois:2)Description avancée

:dd:2.1) Support noyau

Pour activer alsa dans le noyau, il faut activer la gestion du son (Device Drivers->Sound) et ALSA (Devices Drivers->Sound->Advanced Linux Sound Architecture).

En général, sur les noyaux fournis avec les distributions Linux, c'est activé en module, il faut donc charger les modules "sound" et "soundcore", mais ne vous préoccupez pas d'eux ils sont chargés automatiquement lorsque l'on charge un driver.

ALSA permet aussi de simuler le comportement de OSS et donc d'utiliser les programmes qui l'utilisent encore (certains jeux par exemple). Dans la configuration du noyau, ils s'apellent "OSS Mixer API", "OSS PCM (digital audio) API" et "OSS Sequencer API", les modules correspondant s'appellant "snd-mixer-oss", "snd-pcm-oss" et "snd-seq-oss".

Note : en général ces modules sont intégrés aux packages noyaux des distributions.

:fou:2.2) Drivers

C'est sans doute la partie la plus importante...

Les drivers permettent de faire reconnaître votre carte son à ALSA. Ils sont très nombreux et il est rare de ne pas trouver de support pour sa carte son.

Cela va des vieilles cartes ISA aux cartes son USB en passant évidemment par toutes les cartes PCI...

Les modules correspondant à ces drivers on un nom commençant obligatoirement par "snd-", ce qui les rend facile à repérer ("modprobe -l | grep snd-" ?).

Note : En génréal les distributions linux fournissent un nombre important de ces modules avec leurs noyaux.

:|2.3) La bibliothèque

Tous les accès aux systèmes sonores se font par cette bibliothèque (libasound.so).

Cela permet notamment une configuration plus simple, et plus personalisée (notamment lecture du fichier .asoundrc dans le répertoire home de l'utilisateur).

Ce mode de programmation permet aussi une meilleure gestion des système multiprocesseurs SMP et SMT (HyperThreading).

Note : Cette bibliothèque s'installe en général en dépendance des utilitaires ci-dessous, mais voici le nom des paquet pour information (si vous savez pour d'autres distribs, dites-le :-D) :

gentoo : alsa-lib

debian/ubuntu : libasound2

:yes:2.4) Les applications

Les outils de base de alsa ("alsa-utils") permettent de gérer et de débugger ALSA.

Ces outils sont :

- aconnect : connexion de ports dans le séquenceur, permet aussi le listage des ports (options -i et -o)

* alsamixer : mixer très complet en ligne de commande permettant de gérer la totalité des entrées/sorties disponibles de chaque driver.

- amidi : lecture et écriture bas niveau des ports "RawMIDI", pour lire des .midi, utiliser aplaymidi/arecordmidi

* aplay : lecture d'un fichier .wav par alsa... très utile pour faire des tests.

- aplaymidi : lecture d'un fichier .midi par alsa

* arecord : enregistrment d'un fichier .wav depuis alsa, utile pour faire de l'acquisition/enregistrement audio.

- arecordmidi : enregistrement d'un fichier .midi depuis alsa

- aseqdump : listage des évènements reçus par les ports séquenceurs (midi) de alsa

- aseqnet : transport des ports séquenceurs par le réseau

- iecset : gestion du statut des ports S/PDIF

* speaker-test : test des haut-parleurs, permet de tester la bonne configuration de alsa

* alsaconf : détection automatique de la carte son, chargement du module et configuration

* alsactl : sauvegarde/chargement de l'état du mixer

Il existe aussi quelques autres applis utiles :

* aoss : permet de lancer les applications utilisant oss en passant par alsa

- alsamixergui : un peu comme alsamixer, mais en graphique

Il existe enfin les "alsa-tools" mais ces programmes seront inutiles pour la plupart des gens...

Note 1 : voici les paquets requis pour avoir tout ceci sont :

gentoo : alsa-utils (alsa-oss, alsamixergui, alsa-tools)

debian : alsa-utils (alsa-oss, alsamixergui)

Note 2 : je considère les programmes avec une étoile comme étant plus intéressants que les autres

Lien vers le commentaire
Partager sur d’autres sites

:dd:3) Configuration

La première chose à faire pour faire marcher sa carte son sous linux avec ALSA, c'est de trouver le driver correspondant à sa carte son.

Pour cela deux solutions s'offrent à vous:

  • on cherche tout seul
    Tout d'abord, utilisez lspci pour lister toutes les cartes son du système :

 $ lspci | grep "Multimedia audio"

  • Cela permet en général d'avoir suffisamment d'infos (chipset sonore notamment) pour une recherche efficace.
    Ensuite, allez sur la page des drivers
http://www.alsa-project.org/alsa-doc , sélectionnez le vendeur et trouvez le nom du module (par exemple, pour une C-Media CMI8738, ce sera "snd-cmipci")
Une fois le module trouvé, chargez-le

 $ modprobe <module>

  • normalement le driver devrait avoir écrit des infos dans le log du noyau

 $ dmesg | tail
[...]
intel8x0_measure_ac97_clock: measured 50182 usecs
intel8x0: clocking to 48000

  • on utilise alsaconf
    alsaconf permet de détecter les cartes son présentes, charger les modules et éventuellement configurer quelques trucs en plus... c'est tout de suite plus facile :chinois:

La carte devrait maintenant être visible dans le fichier /proc/asound/cards listant toutes les cartes disponibles.

Par exemple, avec une Sound Blaster Live! 5.1, /proc/asound/cards contient ceci, une fois le driver snd-emu10k1 chargé :

 $ cat /proc/asound/cards
0 [Live		   ]: EMU10K1 - SB Live [Unknown]
				 SB Live [Unknown] (rev.10, serial:0x100a1102) at 0xd000, irq 169

À partir de là, c'est presque gagné, il reste encore à augmenter tous les volumes de la carte son avec la commande "alsamixer" (ne pas oublier d'enlever le muet de tous les canaux avec la touche M : il faut OO et non pas MM pour chaque volume).

Maintenant vous pouvez tester si le son marche à l'aide de la commande "speaker-test" (neige audio) et "speaker-test -t 2" (fréquence fixe).

Et voilà! :fou:

Maintenant vous pouvez écouter de la musique avec tous les programmes compatibles alsa...

Bon, puisque un programme OSS peut toujours pointer son nez, on charge les (3) modules correspondants à l'amulation oss, ce qui permet aux programmes OSS de marcher quand même (Mais il vaut quand même mieux configurer les logiciels pour utiliser alsa...).

Les fichiers de configuration de alsa sont /etc/asound.conf et ~/.asoundrc

Ils peuvent ne pas exister (l'un, l'autre, ou les 2), mais alsa essaye toujours de les charger dans l'ordre (ça marche comme un .bashrc quoi... :|)

Lien vers le commentaire
Partager sur d’autres sites

:chinois:4) dmix

(ou "mais pourquoi je peux pas écouter 2 sons à la fois?")

Sur certaines cartes son (par exemple beaucoup de compatibles AC'97 de base intégrés aux cartes mères), il n'est pas possible d'écouter 2 flux audio (ou plus) simultanément.

Les autres cartes son font ce qu'on appelle du "Hardware mixing" (mixage matériel, géré par la carte son directement), mais ceci est indisponible sur certaines, que ce soit pour des raisons matérielles (chip sonore ne le permettant pas) ou logiciel (driver n'utilisant pas 100% des capacités du chip sonore car il a été créé par reverse-engineering, c'est le cas du driver pour les cartes nForce)...

Il faut donc faire du "Software mixing" (mixage logiciel).

C'est possible de le faire de plusieurs façons :

:dd:4.1) Serveur de son

Un "serveur de son" est un logiciel qui collecte le son des différents programmes, les rassemble et crée une seule connexion au système sonore (à ALSA, quoi).

Le seul inconvénient de ce système est qu'il n'est pas standard et qu'il faut donc utiliser une API spéciale pour l'utiliser (ce qui reviendrait donc à modifier à peu près tous les logiciels qui produisent du son pour qu'ils puissent l'utiliser).

(Les serveurs de son induisent aussi quelques fois de la latence, ce qui peut être assez désagréable dans certains cas)

Comme serveur de son, il y a notamment arts (le serveur de son de KDE) et esd (le serveur de son de enlightenmt).

Pour utiliser un serveur de son, il faut tout d'abord le lancer. KDE lance le serveur arts (artsd) dès qu'il se lance, mais si on n'utilise pas KDE il faut le lancer à la main. (même chose pour esd)

Et enfin configurer l'application que l'on souhaite utiliser pour qu'elle passe par le serveur de son.

:fou:4.2) dmix

dmix est intégré à ALSA et fait le software mixing.

L'avantage par rapport aux serveurs de son, c'est qu'il utilise l'interface alsa standard, et est donc compatible avec toutes les applis utilisant déjà ALSA.

Aucune modification dans les programmes déjà écrits pour ALSA n'est donc nécécessaire, il faut juste configurer un peu ALSA.

Il faut donc mettre ceci dans le fichier de conf de alsa :

(/etc/asound.conf pour une configuration pour tout le monde)

(~/.asoundrc pour un configuration perso)

pcm.!default

{

    type plug

    slave.pcm "dmix"

}

On dit à alsa d'utiliser dmix par défaut

(on utilise ici le dmix préconfiguré, voir plus loin pour des détails).

Lien vers le commentaire
Partager sur d’autres sites

:arrow:5) dmix+émulation oss

(ou "Mon logiciel utilise OSS donc je ne peux pas utiliser dmix et avoir plusieurs flux audios simultanés :'( ")

Pour résoudre ce problème, il faut utiliser aoss et configurer un peu ALSA :

pcm.dsp0

{

    type plug

    slave.pcm "dmix"

}

On dit à alsa d'utiliser dmix pour les appels à /dev/dsp0

Cela ne suffit pas, il faut ensuite appeler le programme à l'aide de "aoss" : "aoss programme"

Cela permet de passer par la configuration de alsa et de tout faire marcher...

Note : certaines applications utilisent "mmap" pour accéder à la carte son, cela peut marcher assez mal.

:arrow:6) dmix avancé

Quelques fois (par exemple sur mon PC) la configuration originale de dmix n'est pas optimale.

Personellement, ce qui m'arrive, c'est que lorsque j'utilise la configuration "dmix" par défaut avec OSS, la lecture de la musique avec mplayer est très saccadée, et avec la plupart des applis il y a des petits problèmes...

Enfin bref, pas top, quoi...

Il est possible de configurer un périphérique de type dmix à la main avec quelques options différentes afin de régler ces petits problèmes...

pcm.mix

{

    type dmix

    ipc_key 2 # doit être unique!

    slave

    {

        pcm "hw:0,0" # doit être un périphérique physique!

        buffer_size 16384 # doit être une puissance de 2!

#      period_time 0

#      period_size 1024 # doit être une puissance de 2!

    }

}

Pour pouvoir utiliser notre périphérique perso, il suffit de changer "dmix" par "mix" dans "pcm.!default" et "pcm.dsp0".

Les deux paramètres commentés ne changent pas grand chose chez moi, par contre buffer_size change radicalement le comportement de l'émulation OSS avec dmix. Faites différents tests pour savoir quelles sont les meilleurs réglages chez vous!

Lien vers le commentaire
Partager sur d’autres sites

:arrow:7) Utiliser plusieurs cartes son

ALSA permet d'utiliser simultanément plusieurs cartes son.

Il suffit de regarder les noms ou les numéros dans /proc/asound/cards et d'utiliser ensuite le programme avec ce nom ou ce numéro.

Par exmple moi j'ai ceci :

 $ cat /proc/asound/cards
0 [Live		   ]: EMU10K1 - SB Live [Unknown]
				 SB Live [Unknown] (rev.10, serial:0x100a1102) at 0xd000, irq 169
1 [AMD768		 ]: ICH - AMD AMD768
				 AMD AMD768 with ALC200,200P at 0xe400, irq 169

La carte numéro 0 s'appelle "Live", la carte numéro 1 s'appelle "AMD768"

Nous allons essayer de faire jouer un .wav avec aplay sur la carte numéro 1 (à savoir l'ALC200 compatible AC'97 de ma carte mère utilisant le module snd-intel8x0)

Soit nous utilisons le nom de la carte ("AMD768") :

 $ aplay -D hw:AMD768

Soit le numéro :

 $ aplay -D hw:1

Et même si on veut le numéro du sous-système de la carte :

 $ aplay -D hw:AMD768,0
$ aplay -D hw:1,0

Quelques programmes peuvent avoir une syntaxe différente, mais en général, c'est "[type]:[carte],[sous-système]"

(par exemple mplayer demande d'écrire les ":" en "=" et les "," en ".")

Pour configurer la carte son par défaut, il y a deux façons :

  • la carte support le hardware mixing
    Dans ce cas là, il suffit de mettre
    pcm.!default { type hw card "AMD768" }
    ctl.!default { type hw card "AMD768" }
    (avec la bonne carte)
  • Maintenant si la carte ne supporte pas le hardware mixing, il va falloir créer un dmix perso (voir plus haut "dmix manuel")
    (Vous devez un créer un pour chaque carte qui ne supporte pas le hardware mixing, avec un nom différent, évidemment)
    Ensuite, suffit de mettre ceci :
    pcm.!default { type plug slave.pcm "mixAMD768" }
    ctl.!default { type hw card "AMD768" }
    (ctl.!default représente le périphérique de contrôle par défaut et n'a donc pas besoin de dmix...)

Lien vers le commentaire
Partager sur d’autres sites

:arrow::arrow: Les jeux

Les jeux linux natifs récents utilisent quelques fois directement alsa, mais ce n'est pas toujours le cas...

  • certains jeux passent par SDL pour gérer le son
    Pour ceux-là il faut changer la variable d'environnement SDL_AUDIODRIVER :

 $ export SDL_AUDIODRIVER="alsa"

  • C'est le cas par exemple pour frozen-bubble
    NeverWinter Nigths utilise SDL, mais son cas un peu spécial : il inclue par défaut une version de libSDL qui n'utilise pas alsa.
    Pour utiliser votre propre libSDL, il faut éditer le script "nwn" à la racine du jeu et enlever "./lib:" de la ligne "LD_LIBRARY_PATH" ou supprimer le contenu du dossier lib du jeu (ou les 2 :))
  • certains jeux utilisent OpenAL
    Pour ceux-là il faut créer un fichier "~/.openalrc" contenant ceci :

(define devices '(alsa))

#(define alsa-out-device default)#choix de la sortie si on veux

#(define speaker-num 2)#nombre de voies

  • Cela suffit normalement...
    UT2004 utilise OpenAL, mais la librairie incluse ne supporte ni alsa ni SDL, et la librairie SDL incluse ne supporte pas alsa...
    Il faut donc supprimer (renommer?) openal.so et libSDL-1.2.so, puis créer des liens symboliques : /usr/lib/libopenal.so -> openal.so et /usr/lib/libSDL.so -> libSDL-1.2.so.0
    Il faut ensuite mettre
    (define devices '(sdl))
    Pour pouvoir avoir un peu de son (mais pas exactement synchronisé... pas cool)
  • certains jeux enfin ne sont pas prévus pour utiliser autre chose que OSS
    Vous pouvez essayer de les lancer avec "aoss" (marche de temps en temps), "artsdsp -m" (marche assez souvent, mais avec un peu de décalage (ne pas oublier de lancer artsd avant)) "esddsp -m" (à vrai dire celui-là n'a jamais vraiment bien marché (ne pas oublier de lancer esd avant)).

Lien vers le commentaire
Partager sur d’autres sites

Merci pour ton tuto, ça va probablement m'aider à faire fonctionner ma carte de son intégrée dans mon vieux Compaq Armada 1500c (Carte de son ESS1869) finalement.

Question bête, est-ce que ALSA devrait se retrouver dans toutes les distributions sous forme de modules ? Ou bien, existe-t-il des distributions qui nécessite l'installation d'un package alsa... ?

Lien vers le commentaire
Partager sur d’autres sites

Question bête, est-ce que ALSA devrait se retrouver dans toutes les distributions sous forme de modules ? Ou bien, existe-t-il des distributions qui nécessite l'installation d'un package alsa... ?

Non en général les modules font partie du package kernel...

Il peut y avoir besoin d'autres packages pour les applis...

D'ailleurs je vais les rajouter au tuto... (je met debian+ubuntu et gentoo parce que c'est ce que je connais, pour les autres distribs faudra me dire)

EDIT : voilà

Lien vers le commentaire
Partager sur d’autres sites

Archivé

Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.


×
×
  • Créer...