Étant donné que l'installation de ce périphérique ne se fait pas automatiquement lors de la mise en place de la distribution, il apparaît souvent que la configuration de cette fameuse carte son est l'une des premières choses que l'on effectue un fois l'opération terminée. À ma connaissance, il n'existe que deux méthodes pour obtenir du son sous Linux ; la méthode ALSA (Advanced Linux Sound Architecture) et la méthode OSS/Free (Open Sound System). La méthode ALSA étant un peu plus compliquée à mettre en oeuvre que celle OSS, je me concentrerais temporairement et uniquement à la simple description de cette dernière. Dès que j'aurais un peu de temps, j'essayerais de compléter la section ALSA de ce document.
Ce petit guide est volontairement simple, il essaye de satisfaire les besoins du plus grand nombre de personnes possibles. Aussi, j'aimerais beaucoup que les lecteurs de ce document me fassent part de leurs impressions et, s'ils voient quoique ce soit à modifier ou à améliorer dans celui-ci, qu'ils n'hésitent pas à me contacter. Merci et bonne lecture à tous.
Par défaut sous Debian GNU/Linux, il n'y a aucun pilote pour carte son
directement intégré dans le noyau. Il nous faut donc insérer dans ce dernier
tous les modules nécessaires au bon fonctionnement de notre périphérique audio
(note destinée aux grands débutants: les modules sont assimilables dans de
très nombreux cas à des pilotes de périphérique ; consulter le
Kernel-HOWTO pour de plus
amples informations). Il existe pour cela un utilitaire avec une interface
en mode texte et qui gère de façon très pratique les modules du noyau Linux
sous Debian: modconf. Avec celui-ci, on peut intégrer n'importe quel(s) module(s)
compilé(s) pour un noyau installé (et en cours d'exécution naturellement...).
Après avoir lancé cet utilitaire, dans une rubrique nommée misc, apparaît une
liste de tous les modules, y compris une bonne partie de ceux qui nous intéressent
particulièrement dans le cadre de ce petit guide. Par exemple, si vous possédez:
Selon votre matériel, il est possible que vous ne trouviez pas le ou les module(s), correspondant à votre carte son. Dans ce cas, il y a deux possibilités : Ou bien le module n'existe pas (il n'a pas été écrit), ou alors il n'est pas encore compilé. Si telle est cette dernière situation, soit vous décidez de recompiler vous même votre propre noyau (voir également ce document-ci: http://nicolaxx.free.fr/docs/noyau/noyau.html), soit vous en installez un autre, tout prêt, déjà pré-compilé. Vous pouvez d'ailleurs en installer un tout neuf en suivant la procédure ci-dessous.
Dans un premier temps, éditez votre fichier /etc/apt/sources.list et ajoutez
y la ligne suivante:
deb http://nicolaxx.free.fr/pub stable linux
Mettez à jour votre base de données de paquets (encore une note destinée aux débutants ; si cela n'est pas déjà fait, il peut-être intéressant de consulter le document suivant à propos des manipulations de paquets sous Debian: http://nicolaxx.free.fr/docs/apt/apt_dpkg.html), comme ceci:
apt-get update
Pour terminer, installez le paquet suivant et répondez aux questions posées lors de l'installation de celui-ci:
apt-get install kernel-image-2.2.19
Il s'agit ici du dernier noyau stable de la branche 2.2 et, à l'heure où j'écris ces lignes, nous en sommes à la version 2.2.19. Ce noyau a été compilé avec une configuration identique à celle du noyau 2.2.18pre21-ide disponible avec la Patate 2.2r2. Ces noyaux restent donc très similaires en de nombreux points, la dernière version réduisant vraisemblablement un peu plus le nombre des derniers problèmes que l'on pouvait encore rencontrer avec la version précédente.
Bien-entendu, vous n'êtes pas obligés de charger les pilotes sous forme de modules. Vous pouvez intégrer ces premiers directement dans le noyau, ils seront alors chargés automatiquement au prochain démarrage du système. Cette technique à ses avantages et ses inconvénients. Concernant en particulier les défauts de celle-ci, il faut savoir qu'il est beaucoup moins commode de passer des arguments aux options des pilotes de sa carte son lorsque ceux-ci se trouvent intégrés directement dans le noyau. Il est donc en général préférable d'opter pour la solution modulaire.
Ensuite, vérifiez que tout s'est correctement déroulé et donc que votre
carte son a effectivement bien été détectée. Aidez-vous pour cela de l'utilitaire
dmesg, à utiliser par exemple de la manière suivante:
dmesg | more
Apparaissent alors de très nombreuses lignes sur l'affichage de votre terminal. Au beau milieu de celles-ci, on peut constater la présence d'un message du type de celui présent ci-dessous (correspondant ici aux lignes que l'on constate généralement avec une carte son SBLive!):
Creative EMU10K1 PCI Audio Driver, version 0.7, 16:20:51 Mar 10 2001 emu10k1: EMU10K1 rev 7 model 0x8026 found, IO at 0xd000-0xd01f, IRQ 3
Relativement à votre carte son, si rien de semblable n'apparaît dans les
lignes du message proposé par l'utilitaire dmesg, il très fort probable que
vous avez oublié quelque chose, ou alors qu'il existe un autre problème. Reprenez
tout depuis le début avant la suite, c'est plus prudent.
Afin de pouvoir exploiter votre carte son, et au cas où ceux-ci ne l'auraient pas déjà été, il est nécessaire de créer ce que l'on appelle les fichiers de périphérique. Avant d'effectuer ceci, assurez- vous de bien avoir les droits du super-utilisateur (root), qui sont bien-entendu nécessaires au bon déroulement de cette étape dite de création des fichiers "spéciaux" (i.e nos fameux fichiers de périphérique). Nous pouvons alors procéder comme ceci:
mknod /dev/dsp c 14 3 mknod /dev/mixer c 14 0
Plus simplement maintenant, un script nous permet d'automatiser un peu
plus cette tâche et donc de nous la faciliter. Très facilement, placez-vous
dans le répertoire /dev où vous y exécuterez la commande suivante:
./MAKEDEV audio
Voila, c'est tout!
Il faut maintenant modifier certains droits d'accès accordés aux utilisateurs classiques, histoire que les fichiers de périphérique précédemment crées ne soient pas uniquement exploitables par le super-utilisateur.
A l'origine, je préconisais une petite combine, solution certes un peu rude, mais qui convenait à la plupart d'entre nous. Néanmoins, elle n'était pas sans poser certains problèmes, le plus important concernait probablement celui de la sécurité. Pour rappel, les commandes proposées étaient les suivantes:
chmod 666 /dev/dsp chmod 666 /dev/mixer
Cette façon de faire ne pose à priori aucun problème particulier, sauf si on est un peu paranoïaque bien-sûr. Seulement, cette manipulation relève plutôt du bidouillage, et c'est en bonne partie pour cette raison qu'il faut suivre à la lettre la recommandation faite dans le titre de cette sous-section.
Voici la méthode que tout le monde devrait normalement suivre. Celle-ci consiste à intégrer chaque utilisateur du système dans un ou plusieurs groupes (d'utilisateurs) particuliers ; sont attribuées à ces groupes certaines permissions permettant l'accès ou non à distinctes ressources du système. Autrement dit, on donne la permission ou non à certaines personnes d'accéder à différentes parties du système, en fonction de leur appartenance à tel ou tel groupe d'utilisateur. Je ne vais trop m'attarder sur le pourquoi, tout ceci est formidablement bien expliqué dans la FAQ de la liste de diffusion des utilisateurs francophones de Debian, dans la section numéro 8 qui traite des permissions. A consulter d'urgence donc : http://www.ens-lyon.fr/~mquinson/debian/faq-french/debian-french-faq.html/index.html
A l'aide d'un petit exemple, nous allons ici prendre un peu de temps pour tenter d'expliquer le plus pédagogiquement possible une des manière de procéder pour mettre en pratique une administration correcte de tous les droits d'accès accordés à ces utilisateurs.
Nous considérons donc ici le super-utilisateur toto, qui souhaite créer un compte utilisateur sur son ordinateur préféré, afin que sa petite soeur adorée frangine puisse écouter diverses sources musicales...
Première étape, nous devons tout d'abord créer un nouveau compte utilisateur.
Fastoche, à l'aide de la commande adduser, qui s'utilise de la manière suivante:
adduser <nomutilisateur> <nomgroupe>
Notez bien que si nous ne spécifions pas de groupe à cette commande, lorsque l'on ajoutera un nouvel utilisateur au système, alors un nouveau groupe au nom de cet utilisateur sera également crée (rien d'alarmant, rassurez vous...). Nous créons donc notre nouveau compte :
adduser frangine
L'utilisateur frangine se retrouvera donc pour l'instant uniquement dans un seul groupe, au même nom que celui de son compte, c'est à dire frangine. Si nous avions déjà eu un groupe de créé et convenant à notre utilisateur frangine - par exemple le groupe emmerdeuses - et, que nous avions souhaité l'y intégrer, alors dans ce cas la commande aurait été:
adduser frangine emmerdeuses
Cette fois, attardons et intéressons nous justement à ces fameux groupes.
Il sont répertoriés dans le fichier /etc/group. Y sont décrits un certain nombre
en son sein, leur(s) fonction(s) ou leur(s) utilité(s) étant expliquées pour
la plupart dans la FAQ citée précédemment et, que vous avez naturellement déjà
tous lu...
Nous nous penchons précisément maintenant sur le cas du groupe audio, c'est
celui la même qui nous intéresse vraiment. Par exemple et pour le moment, un
simple grep audio /etc/group nous renvoie ceci:
audio:x:29:
La structure d'une ligne décrivant un groupe est la suivante, composée de quatre champs:
<nomdugroupe>:<motdepasse>:<numerodugroupe>:<utilisateur_admis1>,...,<utilisateur_admisX>
C'est à dire que dans notre cas présent, le groupe s'appelle audio, et
le mot de passe qui lui est associé est ici caché (ne vous souciez pas de ce
champ, il est différent selon les configurations. Ici les mots de passe sont
stockés ailleurs ; tout ça pour dire que x ne correspond pas au mot de passe
réel. Bref, je m'égare...). Les deux derniers champs correspond respectivement
au numéro d'identification du groupe (il est unique et vaut ici 29), suivit
ensuite de tous les noms des comptes utilisateur faisant partie de ce groupe,
ces noms étant séparés pas des virgules. Ici, il n'y rien, donc aucun utilisateur
classique n'est habilité à utiliser les ressources attribuées au groupe audio.
Le groupe audio maîtrise donc par exemple (et entre autres), la ressource
/dev/dsp. Un simple ls -ls /dev/dsp doit normalement nous en rendre compte,
donnant vraisemblablement la sortie suivante:
crw-rw---- 1 root audio 14, 3 Mar 24 14:51 /dev/dsp
Pour que notre utilisateur frangine puisse avoir accès à cette ressource,
il nous faut l'intégrer à ce fameux groupe audio. Encore une fois, rien de
plus facile. Toujours à l'aide de la commande adduser, comme cela:
adduser frangine audio
Littéralement: "le dictateur toto décrète que frangine est autorisé à lorgner
et vandaliser tout ce qui porte la marque audio". Pour le reste, c'est presque:
"tu peut te brosser frangine" (TM)...
La description du groupe audio dans /etc/group a normalement changé et
devrait désormais correspondre à ceci:
audio:x:29:frangine
Simple, non?
Bien. Normalement tout doit être en ordre de marche et il nous ne reste maintenant plus qu'à regarder si tout fonctionne convenablement. Afin de vérifier ceci, il est par exemple possible d'installer les logiciels suivants:
aumixxmmscdcd et/ou
xmcdTout d'abord, si vous n'entendez rien sortir des haut-parleurs de vos enceintes,
vérifiez alors immédiatement que les niveaux sonores de vos sorties audio sont
suffisamment élevés (aidez vous des tables de mixage logicielles du type aumix,
gmix (paquet gnome-media) ou tout autre selon vos préférences). Ensuite pour
le reste des problèmes et, avant tout autre chose, regardez logiquement si
vous n'avez pas sauté certaines étapes et avez effectué correctement les manipulations
décrites dans chaque section de ce document.
Revenons à l'exemple de la sous-section 2.3. Tout heureux d'avoir réussi à intégrer convenablement frangine dans le groupe des utilisateurs habilités à exploiter les extraordinaires méga-possibilités du sous ensemble audio de sa machine, le super-utilisateur toto est soudain confronté à un grand cri déchirant son paisible repos:
"Toto t'es qu'un nâze! Tu m'avais juré que ton truc marchait et je constate que je peux même pas utiliser mes cédés audio! [suivent les insultes habituelles]"
Plutôt qu'un nâze, toto est surtout un grand étourdi. Il a bien donné à
frangine l'accès aux ressources attribuées au groupe audio, celles-ci correspondant
donc aux entrées et sorties de la carte son. Pour que frangine puisse entendre
quelque chose sortir des enceintes audio (la destination, la sortie sonore),
il faut que toto lui libère l'accès aux ressources du cédérom (l'entrée, la
source sonore). Sous Debian, c'est le groupe cdrom qui détient les droits d'accès
à ce périphérique. La solution est donc:
adduser frangine cdrom
Bien-entendu, cet exemple est valable pour n'importe quelle source/destination
à attribuer en fonction de l'utilisation des ressources du groupe audio.
Si malgré tout vous n'avez toujours pas réussi à faire fonctionner votre
carte son, peut-être faut il chercher des solutions visant à régler le ou les
problème(s) ailleurs. Pour l'instant, je n'ai eu qu'une seule fois un retour
me parlant d'une carte son qui s'obstinait à n'émettre aucun son... Le problème
a été résolu en supprimant le paquet yiff-server, qui devait probablement être
mal configuré et/ou empêchait OSS fonctionner correctement.
A priori plutôt rien à voir avec les flans ; la suite pour bientôt (et moins désespérante, promis...).