Le partage de son sous Linux
Nicolas George
ce sujet ici ou là, donc j'ai décidé de prendre le temps d'écrire un petit
topo.
Le partage de son sous Linux
============================
Nicolas George, le 2005-03-26
(Toutes copies ou citations autorisés à condition d'indiquer la source.)
Ce document n'est pas un HOWTO, ce serait plutôt un « how I did », sur
comment permettre à plusieurs applications de sortir du son en même temps.
Dans un premier temps, j'énoncerai un certain nombre de points, pour que
tout le monde ait les idées claires, et ensuite j'expliquerai en détails un
exemple de configuration, avec en particulier les raisons des choix.
1. Comment marche le son sous Linux
-----------------------------------
1.1. Comment on fait du son sur ordinateur
Une carte son est un composant d'un ordinateur multimédia moderne qui permet
de produire du son de qualité : musique, voix, bruitages, etc. Le terme
carte vient de l'époque où un tel composant était relativement rare sur les
PC, et vendu séparément sous la forme d'une carte d'extension ISA. Depuis,
le terme est resté même si le composant se présente comme un bout de puce
sur la carte mère ou un boîtier branché en USB.
Le principe du fonctionnement d'une carte son est très simple : le
processeur lui envoie des données via le bus, et la carte son convertit ces
données en signal pour les hauts-parleurs. La manière dont sont codées ces
données envoyées à la carte son peut être très variable. Historiquement, on
confiait à la carte son le boulot de générer une grande partie du signal par
elle-même. C'est ainsi que fonctionnait la carte AdLib, le processeur
envoyant les paramètres de plusieurs oscillateurs (fréquence, amplitude), ce
qui revient en gros à envoyer des notes de musique et une vague description
des instruments.
Avec l'augmentation de la vitesse des bus et des capacités de stockage, un
codage plus simple et plus générique s'est imposé : le son échantillonné,
dit PCM : le code envoyé par le processeur à la carte son est une
représentation numérique directe du signal électrique que la carte son doit
envoyer au haut parleur. Cette représentation est beaucoup plus gourmande
(plusieurs milliers d'octets par seconde, contre quelques octets par note),
mais permet de coder n'importe quel son à peu près fidèlement.
Les cartes son actuelles sont quasiment uniquement utilisées en PCM. Elles
offrent encore, souvent, le nécessaire pour faire de la synthèse
elles-mêmes, mais c'est peu utilisé en dehors d'applications spécifiques. Et
d'ailleurs je n'ai jamais réussi à le faire marcher sous Linux, donc je n'en
parlerai pas ici.
Les cartes son modernes ont souvent plusieurs canaux PCM : le processeur
peut envoyer deux flux de données à la carte son, presque comme s'il y avait
deux cartes son différentes, et la carte son se charge de mélanger le tout
pour l'envoi aux hauts parleurs. Bien sûr, le nombre de tels canaux est
forcément borné, souvent à deux ou trois.
1.2. Les drivers de cartes son sous Linux
1.2.1. OSS
OSS, pour Open Sound System, est l'évolution moderne des tous premiers
drivers de cartes son de Linux (le support pour les Sound Blaster et Gravis
Ultrasound est arrivé avant la version 1.0). Les drivers OSS existent en
version libre dans le noyau officiel, et en version propriétaire
commerciale, plus complète. Leur interface est très simple : un
périphérique, /dev/dsp (ou /dev/dsp1, dsp2, etc. ; ou encore /dev/sound/dsp
si on utilise devfs) correspond directement à un canal PCM. On écrit dans ce
périphérique pour sortir du son, on lit pour enregistrer, et quelques ioctl
servent à changer les paramètres (fréquence d'échantillonage, mono/stéréo,
etc.).
Ainsi, avec OSS, on peut souvent enregistrer simplement avec
« cat /dev/dsp > fichier » et le rejouer avec « cat fichier > /dev/dsp ».
À noter que l'interface OSS est également disponible sous d'autres Unix
libres.
1.2.2. ALSA
ALSA, pour Advanced Linux Sound Architecture, est une réécriture complète du
système sonore de Linux, pour le doter d'une architecture plus moderne et
plus facile à maintenir et étendre. Du point de vue du noyau, ALSA présente
divers devices dans /dev/snd/, mais leur signification n'a pas à être
connue : ils ne doivent pas être utilisés directement par les applications,
mais uniquement au travers d'une bibliothèque, elle aussi fournie par le
projet ALSA.
Comme beaucoup de vieilles applications sont écrites spécifiquement pour
OSS, avec directement l'ouverture de /dev/dsp, etc., ALSA prévoit un mode de
compatibilité : un module ALSA permet de faire apparaître un /dev/dsp qui
est un point d'accès à la carte son gérée par ALSA.
Un gros avantage d'ALSA est que l'utilisation d'une bibliothèque commune
permet d'implémenter en dehors du noyau des fonctionnalités plus étendues,
comme la lecture d'un fichier de configuration et le chargement de plugins.
La bibliothèque d'ALSA implémente ces deux fonctionnalités. Le fichier de
configuration s'appelle /etc/asound.conf et ~/.asoundrc, et les plugins
permettent différents effets comme changer la fréquence d'échantillonage ou
créer des cartes son virtuelles qui sauvent sur disque.
1.2.3. Accès simultané
Pour OSS comme pour ALSA, le choix au niveau des drivers dans le noyau a été
de coller au plus près au fonctionnement du matériel. Les devices /dev/dsp
ou /dev/snd/* donnent accès chacun à un canal PCM, presque directement. À ce
titre, chaque device ne peut être utilisé à un instant donné que par au plus
une application.
Si plusieurs applications tentent d'utiliser un même device, la seconde va,
selon les cas, ne pas pouvoir ouvrir le device ou, pire, se retrouver
bloquée dans l'ouverture jusqu'à ce que la première le ferme (ou ce que
l'utilisateur l'interrompe).
1.3. Partager l'accès aux devices
La méthode standard, sous Unix, pour mutualiser l'accès à une resource
disponible en un seul exemplaire est d'avoir un serveur pour la gérer. C'est
comme ça qu'est géré l'écran (avec les serveurs X11), l'imprimante (avec
lpd, et maintenant CUPS). La même solution a bien entendu été utilisée pour
l'accès à la carte son.
1.3.1. ESD
ESD, pour Enlightenment Sound Daemon, est le premier tel serveur, ou au
moins un des premiers. Il a été créé pour permettre au window manager
Enlightenment de faire des zigouigouis sonores. Le fonctionnement est très
simple : le serveur esd écoute des connexions réseau, mélange les signaux,
et envoit le tout au device sonore.
1.3.2. ARTS
ARTS, pour Analog Realtime Synthetizer, fonctionne sur le même principe,
mais de manière plus évoluée : les clients peuvent envoyer des objets plus
complexes, comme du son codé en Vorbis ou en MP3, et des indications
d'effets spéciaux à appliquer. ARTS est le coeur du système sonore de KDE.
1.3.3. JACK
JACK, pour JACK Audio Connection Kit, est encore un autre serveur de son,
plus simple qu'ARTS, mais un peu plus performant qu'ESD.
1.3.4. Inconvénients des serveurs de son
Les serveurs de son fonctionnent, et apportent en outre la possibilité d'une
transparence réseau. Mais leur fonctionnement induit une certaine lourdeur :
les données doivent passer plusieurs fois par le noyau, et être recopiées à
chaque fois.
Et surtout, la présence de plusieurs tampons successifs (tampon de la
connexion réseau, tampon du device PCM) induit une latence entre le moment
où un son est émis par une application et celui où il arrive aux hauts
parleurs. Cette latence peut être de plusieurs dixièmes de seconde. À titre
de comparaison, pour un film, une désynchronisation d'un dixième de seconde
entre le son et l'image est bien perceptible, et au delà de trois ou quatre
dixièmes, elle devient franchement gênante.
En outre, il faut qu'une application ait été prévue pour fonctionner avec un
tel serveur. Si ce n'est pas le cas, il y a plus ou moins moyen de récupérer
avec des histoires de surcharge de bibliothèque partagée, mais ça fonctionne
forcément mal.
1.3.5. Le plugin dmix
La bibliothèque ALSA propose un plugin, dmix, qui permet de partager l'accès
à un canal PCM en utilisant de la mémoire partagée comme tampon d'écriture
dans la carte son. Cette approche est plus efficace que le modèle
client-serveur. De plus, comme le plugin est géré directement par la
bibliothèque ALSA, tous les programmes qui utilisent ALSA peuvent être
configurés d'un seul coup pour l'utiliser.
2. Ma configuration d'ALSA, de dmix et des applications
-------------------------------------------------------
2.1. Configuration d'ALSA
J'utilise un noyau 2.6, ALSA est présent directement dans les sources, il
suffit de sélectionner les bons modules dans la liste. Pour les noyaux
précompilés par des distributions, les modules seront très certainement
facilement disponibles. Quant à la bibliothèque, elle était disponible comme
paquet pour ma distribution, je n'ai rien eu à faire.
Pour utiliser ALSA, il n'y a pas grand chose à faire. Il suffit de
convaincre les scripts de boot de ne pas charger les modules OSS, puis de
charger le module ALSA correspondant à la carte son. Pour moi, c'est
snd_ens1371. Je sais qu'il existe des outils de détection automatique, par
exemple alsaconf, mais pour ma part je ne les utilise pas.
Il est bon de charger également les modules snd_pcm_oss et snd_mixer_oss
pour permettre aux applications qui ne connaissent qu'OSS de faire quand
même du son.
Pour tester, se contenter d'un modprobe manuel devrait faire l'affaire. Pour
pérenniser la situation, je laisse chacun consuter la documentation de sa
distribution.
À noter que tout ceci n'est pas utile si ALSA est déjà utilisé, ce qui se
constate par la présence de modules en snd_* ou d'un répertoire
/proc/asound/.
2.2. Configuration de dmix
2.2.1. Choix techniques
Je commence par regarder mon fichier /proc/asound/devices :
8: [0- 0]: raw midi
17: [0- 1]: digital audio playback
16: [0- 0]: digital audio playback
24: [0- 0]: digital audio capture
0: [0- 0]: ctl
33: : timer
Je constate ainsi que ma carte son possède deux canaux de sortie exactement.
Je vais les utiliser ainsi : le canal 0 sera dédié exclusivement à la sortie
sonore efficace, et en premier lieu la sortie sonore de mplayer pour
accompagner les vidéos ; le canal 1 sera dédié au tout venant, bruitages de
jeux, lectures sonores ponctuelles, etc., et donc sera utilisé via un plugin
dmix.
2.2.2. Petite configuration préliminaire
Je vais commencer par quelques petites opérations préliminaires. Toutes les
options de configuration vont dans ~/.asoundrc.
Les canaux de la carte son s'appellent normalement hw:0,0 et hw:0,1, ce qui
n'est pas très pratique à taper. Je vais les appeler c1 et c2 :
pcm.c1 {
type hw
card AudioPCI
device 0
}
pcm.c2 {
type hw
card AudioPCI
device 1
}
À noter que j'aurais pu utiliser 0 à la place de « AudioPCI », mais j'ai
préféré utiliser le nom, que j'ai trouvé dans /proc/asound/cards :
0 [AudioPCI ]: ENS1371 - Ensoniq AudioPCI
Ensoniq AudioPCI ENS1371 at 0xb000, irq 11
Je peux tester que ça fonctionne bien en lançant deux mplayer
simultanément :
mplayer -ao alsa:device=c1 fichier1
mplayer -ao alsa:device=c2 fichier2
2.2.3. C'est parti pour dmix
Voici la configuration basique d'un canal dmix, telle que pompée dans la doc
d'ALSA.
pcm.mixer { # The mixer plugin
type dmix
ipc_key 1024
slave { # The hardware output
pcm c2
period_time 0
period_size 1024
buffer_size 4096
rate 48000
}
bindings { # Stereo bindings: left to left, right to right
0 0
1 1
}
}
Cette fois-ci, je peux tester mplayer avec le périphérique mixer :
mplayer -ao alsa:device=mixer fichier1
mplayer -ao alsa:device=mixer fichier2
2.2.4. Un peu de paramétrage
Ceci ne me satisfait pas tout à fait, car je souhaite pouvoir passer des
paramètres en plus, et en particulier pouvoir régler le volume pour chaque
application si besoin est. Je rajoute donc un plugin route et des paramètres
variables :
pcm.mixer { # The mixer plugin
@args [ V RATE ]
@args.V { # The volume factor
type real
default 1.0
}
@args.RATE { # The sample rate, should be fixed
type integer
default 48000
}
type route
slave.pcm {
type dmix
ipc_key 1024
slave { # The hardware output
pcm c2
period_time 0
period_size 1024
buffer_size 4096
rate $RATE
}
bindings { # Stereo bindings: left to left, right to right
0 0
1 1
}
}
ttable { # Volume factors
0 { 0 $V }
1 { 1 $V }
}
}
Maintenant, je peux choisir le volume en utilisant comme périphérique ALSA
« mixer:0.1 » (pour un volume de 1/10). Hélas, je ne peux plus tester avec
mplayer, car il ne permet pas de passer un point dans le nom du device. Avec
aplay, ça fonctionne.
Ce canal PCM mixer n'est pas encore parfait, car il ne fonctionne qu'à
48 kHz. Un plugin plug devrait faire l'affaire pour que la bibliothèque
fasse la conversion nécessaire, et de fait ça fonctionne avec différentes
applications. Hélas, mplayer n'utilise pas ALSA correctement, et il va
falloir ruser. Je rajoute donc un plugin de rééchantillonage. La version
finale est :
pcm.mixer {
@args [ V RATE ]
@args.V { # The volume factor
type real
default 1.0
}
@args.RATE { # The sample rate, should be fixed
type integer
default 48000
}
type route # The volume-scaling plugin
slave.pcm {
type rate # The resampling plugin
slave.rate $RATE
slave.pcm { # The mixer plugin
type dmix
ipc_key 1024
slave { # The hardware output
pcm c2
period_time 0
period_size 1024
buffer_size 4096
rate $RATE
}
bindings { # Stereo bindings: left to left, right to right
0 0
1 1
}
}
}
ttable { # Volume factors
0 { 0 $V }
1 { 1 $V }
}
}
2.2.5. En faire le défaut
Les applications ALSA utilisent par défaut le device « default ». Donc je
rajoute :
pcm.!default {
type plug
slave.pcm mixer
}
À noter que le fait d'utiliser un plugin plug permet à la bibliothèque ALSA
de changer la fréquence d'échantillonage ou les paramètres à la volée.
2.2.6. Goodie
Je modifie default de cette manière :
pcm.!default {
@args [ D ]
@args.D {
type string
default {
@func getenv
vars [ ALSA_PCM ]
default "mixer"
}
}
type plug
slave.pcm $D
}
Le nom du canal de sortie est lu depuis la variable d'environnement
ALSA_PCM. Ça permet entre autres de configurer les applications qui n'ont
pas prévu de choix du device, ainsi que de contourner la limitation de
mplayer sur le caractère point :
ALSA_PCM="mixer:0.1" mplayer -ao alsa:device=indirect fichier
À noter que l'utilisation de tous ces plugins commence à se voir assez
nettement sur l'utilisation CPU. Mais ça reste assez raisonnable : 2%
supplémentaires dans mon cas, ça reste exploitable sur les ordinateurs de
moins de six ou sept ans (à la date où j'écris cet article) sans aucun
problème.
À noter également que la configuration par défaut d'ALSA prévoit aussi une
configuration par variable d'environnement, mais uniquement entre les
différentes cartes son et canaux physiques.
2.3. Configuration des applications
Il reste maintenant à convaincre les applications que j'utilise
quotidiennement d'utiliser ALSA, et le bon device. Comme pour le tout
venant, le device ALSA est « default », il n'y a pas grand chose à faire au
delà de l'utilisation d'ALSA sur celles qui connaissent plusieurs systèmes.
Selon les applications, la manière de faire est variable. Cependant,
beaucoup d'applications utilisent différentes bibliothèque fréquentes pour
gérer la sortie sonore. Pour savoir si un programme utilise telle ou telle
bibliothèque, le plus simple est de regarder ses dépendances, soit au niveau
du gestionnaire de paquets (ici, Frozen Bubble sous Debian) :
Depends: libsdl-perl (>= 1.20-8), perl (>= 5.8.4-2), perlapi-5.8.4,
libc6 (>= 2.3.2.ds1-4), libsdl-mixer1.2 (>= 1.2.5),
libsdl1.2debian (>> 1.2.7-0), frozen-bubble-data (= 1.0.0-6),
fb-music-high | fb-music-low
Je vois ici qu'il dépend de SDL. Soit au niveau du binaire, avec ldd :
$ ldd =ogg123
libvorbisfile.so.3 => /usr/lib/libvorbisfile.so.3 (0x40028000)
libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0x40030000)
libao.so.2 => /usr/lib/libao.so.2 (0x40059000)
libnsl.so.1 => /lib/tls/i686/cmov/libnsl.so.1 (0x4005e000)
<snip>
Je vois ici qu'il dépend de la libao.
2.3.1. libao
La libao, pour audio output, est une bibliothèque générique de sortie sonore
développée par le projet Xiphophorus. Pour convaincre les applications
utilisant ao d'utiliser ALSA, il suffit de mettre « default_driver=alsa »
dans ~/.libao.
2.3.2. SDL
SDL, pour Simple DirectMedia Layer, est une bibliothèque multimédia, souvent
utilisée pour les jeux, avec évidemment des modules sonores. Pour la
convaincre d'utiliser ALSA, il faut positionner une variable
d'environnement : SDL_AUDIODRIVER=alsa. Une méthode encore plus simple, au
moins sous Debian, est de prendre une version de SDL qui n'est compilée
qu'avec support d'ALSA.
2.3.3. Allegro
Allegro est une bibliothèque prévue pour les jeux. Apparemment, pour la
convaincre d'utiliser ALSA, il faut mettre dans ~/.allegrorc une ligne
disant « digi_card = ALSA » après une ligne « [sound] », mais je n'ai pas
testé.
2.3.4. mplayer
Pour mplayer, il faut passer l'option « -ao alsa », ou mettre la ligne
« ao=alsa » dans ~/.mplayer/config. Si on souhaite lui faire utiliser autre
chose que le device par défaut, il faut écrire « alsa:device=c1 » (pour le
device c1).
2.3.5. xmms
Pour xmms, il faut aller dans Options, Preferences, choisir ALSA parmi les
Output Plugins, et choisir le nom du device dans la boîte de dialogue
Configure.
2.3.6. ARTS
Il est possible que KDE insiste pour utiliser ARTS de toutes façons. Dans ce
cas, l'option « -a alsa » est censée faire ce qu'il faut. N'utilisant pas
KDE, je ne sais pas où au juste on a la possibilité de la configurer.
2.3.7. Les applications OSS
Génériquement, rien n'est possible. Mais, en tout cas dans mon cas,
l'émulation OSS d'ALSA travaille sur le premier canal PCM de la carte son.
Dans la configuration que j'ai donnée, les applications OSS seront alors en
conflit entre elles, et avec une application ALSA réglée pour utiliser le
device c1, mais pas en conflit avec le device c2, sur lequel se trouve le
plugin dmix.
On ne peut de toutes façons qu'espérer que les applications purement OSS
disparaissent au profit d'applications configurables, utilisant ao ou SDL
par exemple.
3. Conclusion
-------------
On entend souvent les gens se plaindre du problème de sortie sonore
simultanée sous Linux. Pourtant, tout le nécessaire est là, et peut se faire
assez efficacement. Tout ce qui manque est un peu de configuration
préalable, qui n'est pour le moment pas faite par les distributions.
J'espère que ce document aura été utile. Je pense qu'il peut aider dans
d'autres cas, comme par exemple à configurer l'utilisation d'une carte son
plutôt qu'une autre quand plusieurs sont présentes.
Toutes les remarques, précisions, corrections, sont bien sûr les bienvenues.
Références :
http://www.alsa-project.org/alsa-doc/alsa-lib/
http://www.libsdl.org/cgi/docwiki.cgi/SDL_5fenvvars
Sébastien Kirche
> Ça fait plusieurs fois ces derniers temps que je vois passer des questions
> à ce sujet ici ou là, donc j'ai décidé de prendre le temps d'écrire un
> petit topo.
>
>
> Le partage de son sous Linux
> ============================
> [...]
Encore un excellent tutoriel dans la même veine que les polices sous X11.
Je n'ai pas encore fini de le lire mais que je me suis empressé de
l'imprimer et d'ajouter à ma collection de docs systèmes.
Décidément, tu as une vocation de vulgarisateur...
En tout cas merci de cette nouvelle contribution.
--
Sébastien Kirche
l'indien
> Le 27 mar 2005, Nicolas George a formulé :
>
>> Ça fait plusieurs fois ces derniers temps que je vois passer des questions
>> à ce sujet ici ou là, donc j'ai décidé de prendre le temps d'écrire un
>> petit topo.
>>
>>
>> Le partage de son sous Linux
>> ============================
>> [...]
>
> Encore un excellent tutoriel dans la même veine que les polices sous X11.
Un seul défault:
il y a pas mal de cartes pour lesquelles le partage des canaux existe en
hardware. Quand le driver OSS a été bien implémenté, il est alors tout
à fait possible que plusieurs applications utilisent simultanément
/dev/dsp. Le problème du partage du son n'est pertinent que lorsqu'on
utilise une carte son bas de gamme (genre carte intégrée à la carte
mère) ou ancienne qui ne supporte pas plusieurs canaux hardware ou bien
lorsque le driver a été codé avec les pieds, et il y en a ! ;-)
Sur les cartes son actuelles, c'est loin d'être une généralité, tout
de même...
TOF
> Ça fait plusieurs fois ces derniers temps que je vois passer des questions
> à ce sujet ici ou là, donc j'ai décidé de prendre le temps d'écrire un
> petit topo.
Excellent, tres clair et detaillé, vraiment !
Même pour quelqu'un comme mois qui ne manie linux que depuis quelques mois a
peine j'ai trouvé tout ces explications simples et tres détaillées (cela
change du : t'as qu'a reconfiguré la conf de ton systeme de son ! où il
n'est pas detaillé les fichiers a modifié, où les trouver et quoi mettre a
la place de quoi)
C'est grace a des tuto aussi bien fait que l'on pourra faire venir davantage
de nouveau utilisateur sur linux sans qu'ils soient degoutés au bout de 10
jours parce qu'il n'arrive pas a configurer (et ce meme si des distrib
comme MDK permettre de faire beaucoup de chose a la souris c'est
malheureusement souvent insuffisant)
pour ma part, mon install de kde (mdk10.1off) par defaut mixe deja les sons
sans probleme (alsa + arts). Mais je n'arrive toujours pas a avoir du son
dans doom3 qui veut utiliser oss et qui trouve /dev/dsp failed:
input/output error, sound subsystem disabled.
On a deja essayé pleins de choses, ici même, mais je ne trouve la solution,
mais je continu de chercher. je vais imprimer et lire attentivement cet
excellent tuto.
Si je trouve la solution dans les jours prochain, je la posterai ici.
encore merci pour vos aides à tous. On se sent moins seul face a son linux
(qu'on aime aussi pour ça ;-))
TOF
cavelier jean-jacques
<alsa$config$dmix$how...@salle-s.org>:
> Ça fait plusieurs fois ces derniers temps que je vois passer des questions
> à ce sujet ici ou là, donc j'ai décidé de prendre le temps d'écrire un
> petit topo.
Bonjour.
Merci.
--
cordialement jean-jacques.
Ce message a été écrit sur un système libre mandrake ver 10.1
Stemp
J'ai enfin réussi à comprendre quelque chose au son sous Linux.
Remi Moyen
> Ça fait plusieurs fois ces derniers temps que je vois passer des questions à
> ce sujet ici ou là, donc j'ai décidé de prendre le temps d'écrire un petit
> topo.
Bon boulot, ça. Bien joué.
Je peux juste compléter un truc :
> 2.3.6. ARTS
>
> Il est possible que KDE insiste pour utiliser ARTS de toutes façons. Dans ce
> cas, l'option « -a alsa » est censée faire ce qu'il faut. N'utilisant pas
> KDE, je ne sais pas où au juste on a la possibilité de la configurer.
Pour la ligne de commande, j'avoue que je sais pas trop (j'ai jamais
réussi à savoir où étaient stockés les configurations des différents
composants de KDE !).
Par contre, en interface, dans le centre de configuration, rubrique
son/serveur de son, il y a un onglet "Matériel", dans lequel on peut
selectionner l'audio device (hum, je mélange allègrement les termes
anglais et français...) : chez moi, j'ai le choix entre autodetect, alsa,
esd, jack, nas, rien, oss ou threaded oss (connait pas ?).
Je vous laisse deviner lequel selectionner pour utiliser alsa :-)
--
Rémi Moyen
"Malgré les apparences, le temps est très varié à Nancy :
pluie, nuages, neige, brouillard, grêle, ..."
Rasmus
> Nicolas George nous disait récemment dans
> <alsa$config$dmix$how...@salle-s.org>:
>
>
>>Ça fait plusieurs fois ces derniers temps que je vois passer des questions
>>à ce sujet ici ou là, donc j'ai décidé de prendre le temps d'écrire un
>>petit topo.
>
>
> Bonjour.
> Merci.
>