Space Menu Home Downloads Kiosk Newbie Area Documentation Knowledge Base E-Training Forum Blogs Chat RPMs Farm Linux Events
Add Comment (3)Add Comment (3) | HistoryHistory |

Et le son ? II

Après un premier survol des diverses possibilités de système de son sous gnu/linux, un léger appronfondissement concernant alsa. la structure du système sonore avec gnu/linux pourrait être ce que décrit à la précédente note. Où on peut donc voir le choix : diverses couches existent, toutes ne sont pas indispensables, toutes sont modulables, certaines s' adressent à du matériel spécifique. L' utilisateur a le choix de configuration, et est parfois restreint par le matériel. Dans tout les cas, on peut à loisir jongler avec diverses solutions pour amener la lecture d' un fichier vers la sortie de la carte son. Ici un "shéma sur ce que pourrait être une visu, loin d' être exhaustive. On peut par exemple placer une appli type xmms au dessus d' un arts, lui même au dessus de oss… Mais par défaut dans bien des cas, c' est à dire sur une mandriva avec carte son ayant un jack d' entrée ainsi que le midi. Avec Alsa et arts, configures par défaut. Ici on voit que cela déjà de nombreuses possibilités.

Focus sur ALSA

interressons nous de plus près à alsa, en tant que centre névralgique d' un système sonore. Néanmoins, toutes les cartes sons ne peuvent fonctionner avec alsa. La liste la plus complète des cartes supportées se trouve à cette adresse : http://www.alsa-project.org/alsa-doc/ Merci de bien vouloir y signaler la votre si celle ci fonctionne avec alsa mais n' apparait pas.

Advanced Linux Sound Architecture est une refonte du système de son pour gnu/linux. Il fonctionne un peu différement de OSS en ce sens qu' il gère le son en incluant une bibliothèque externe au noyau, permettant d' étendre plus facilement ses possibilités. Il à donc été conçu comme entièrement modulaire et sans avoir une meilleure api. Il assure une couche de compatibilté maximale avec oss. Alsa permet donc de faire plus de choses et plus facilement qu' avec oss. On pourra observer que /proc/asound existe et qu' il recense les cartes sons utilisables. Par exemple less /proc/asound/card0/pcm0c/info donnera aussi des informations interressantes, le sous ensemble asound étant typique de alsa.

La commande amixer, en utilisateur, vous donnera les possibilités de cette configuration. Amixer permet aussi, comme alsamixer, de passer des arguments à alsa, afin de changer le volume de différents canaux, d' ajuster le gain et autres… A noter que amixer fait parti du rpm alsa-utils et alsamixeur possède une "gui" en console et une en graphique. Il est également souvent possible d' ajuster ces options par le biais de différentes applications types lecteurs.

On peut donc passer des options au module utilisé, que cela soit par le MCC ou par options snd-nom du module. Mais d' ou sortes les valeurs initiales pour ces options ? Elles correspondent à ce que le bios de la machine contient. Ils peuvent être modifier ici, an passant donc des options au module, voir en y ajoutant d' autres peut être...

Mais que sont les fichiers /dev/snd/ ? Ces fichiers donc sont les interfaces à alsa. On y trouve le pcm, le mixeur, éventuellement le raw-midi et autres. Vous y passer des options avec les autres interfaces, citées plus haut. Les programmeurs se servent de la librairie externe asound pour y contrôler les éléments, parait il (!)

Alsa a également une couche de compatibilité avec oss, ce qui permet à l' immense majorité des applications utilisant oss d' être utilisable avec alsa aussi. Et mêmes certains vieux jeux & appli oss dont le son ne marche pas ou-of-the-box sont donc configurables soit eux mêmes, soit en modifiant le système de son.

Alsa & les applications, le cas xmms :

xmms propose par défaut oss mais il possible d' y ajouter alsa. Il attaquera directement alsa. ( Ce qui implique que celui ci est la voie libérée par arts, ou que tout kde est été configuré en alsa et arts arreté) Si des évenements sonores se produisent, quelque soit leur source, par le système alsa, il seront audibles en même temps que xmms joue.

On peut également configurer xmms pour qu' il attaque arts, qui lui même peut attaqué alsa. Si des sons des événements kde sont émis dans une configuration kde par défaut, alors on pourra les entendre pendant que xmms joue.

On retrouvre donc bien ici nos "couches" initiales. Dont certaines, comme arts, gstreamer, ne sont pas indispensables. Le cas où le plus de choses fonctionnent, ensembles et au mieux, est celui ou tout est alsa. Ceci n' est alors limité que par quelques applications, ne tournant qu' avec oss, comme certains vieux jeux qui monopolisait le "son".

La plupart des applications ayant recours au son ont donc des configurations propres à elles, mais toutes ne présentent pas les mêmes : certaines étant plus "complètes" que d' autres.

A note que l' interface graphique de certaines applications "brouille un peu les cartes". Comme amarok ( ce qui n' empeche nullement son excellent fonctionnement:) ) qui emploi xine et gstreamer comme choix dans "moteurs". Car xine est lui même configurable pour donner à manger le son à oss, alsa, arts et d' autres… Mais peut être gstreamer n' est il pas vraiment comme arts ? … ;)

Alsa, configuration & matériel : commandes utiles

A noter que certaines cartes peuvent nécessitées la présence des isapnptools. Et que certains logiciels les ont en dépendance, même si le matériel n' en pas directement besoin.

Dans une console root :

  • lspcidrake - v | grep AUDIO -> donne le type de carte, ses références ainsi que le nom du module kernel -driver- associé.
  • cat /proc/asound/cards -> donne la-les carte-s actuellement utilisees
  • ll /dev/ | grep dsp -> donne les droits sur le fichier dsp. Plusieurs fichiers dsp peuvent être présent, selon la ou les cartes sons présente-s, détèctée-s & fonctionnelle-s.
  • modinfo nom du module Vous en dira plus. Et certainement que ce module peut prendre en entrée certains arguments spécifiques. Hardrake2 vous permettra de les configurer plus facilement. Se reporter au site de chacun des modules pour une éventuelle aide sur les options proposées.
  • les fichiers /dev/audio et /dev/dsp sont typiquement utilisé par oss. Ils vont l' être églement si la couche de compatibilité alsa-oss a été installée : fuser -v /dev/dsp -> donne le processus, son pid et son utilisateur, d' une application utilisation le fichier dsp. si vous êtes sous un kde par défaut et faire cette commande, a noter qu' arts est lancé mais se coupe après toute inutilisation. Ce qui donne alors une réponse vide, comme dans le cas où, sous alsa directement, aucune application n' est lancée
  • fuser -k /dev/dsp -> tuera tout accès au fichier dsp, typiquement oss...
  • killall arstd -> tuera grossirèment arts.
  • Service alsa stop ou /etc/init.d/alsa stop -> arrèterons le daemon alsa. Un éventuel service sound stop est certainement possible.
  • rmmod nom du module enlevera le module au noyau. On reboot ? Non.
  • modprobe -> re-injectera le module au noyau. on reboot ? tjs pas.
  • service alsa start && chkconfig --add alsa. reboot ? heu t es lourd
  • Une animation pour hardrake2 On peut également regardé drakxservices pour l' arrêt et le redémarrage de alsa et sound.
On peut donc choisir d' arreter complètement arts. On peut choisir de le conserver. Vérifier alors qu' il rétrocède bien à alsa et réduire son temps de latence avant mise en veille. Ainsi que spécifier full-duplex et un taux d' échantillonage personnalisé, lorqu' il fonctionne. Voir l' animation

Pour alsa directement, on peut vérifier avec : amixer master 100 unmute

Voilà un système prêt & fonctionnel : les 'évènements' kde signalés par un son passeront donc soit par arts-alsa, soit par alsa directement selon le choix fait dans la configuration de kde -> système de son.

Note

On peut commencer à le voir, le son sous gnu/linux et sa liberté qui "nous complique la tache' n' est qu' une expression pour désigner les capacités. Loin du dogme d' une seule api, avec éventuellement quelques notions de hierarchie de volumes pour l' utilisateur : 'nous' pouvons configurer au plus finement. 'Nous' pouvons également faire du sur mesure, de la 'haute couture'. Le son étant un exemple typique de ce que permet l' open-source. Une apparente problématique pour l' utilisateur qui recèle une multitude de possibilités.

  • A noter enfin que sur mandriva, les configurations se resument bien souvent à installer paquet correspondant pour que tout fonctionne out-of-the-box. urpmi libalsa-oss0 par exemple. A noter enfin qu' elle configure également une multitude de cartes sons et supporte immédiatement l' utilisation de plusieurs cartes simultanément.
  • Mais alors, est ce réellement utile, savoir ceci ? Non, effectivement, pour tout faire fonctionner : pour d' éventuels ajouts à que l' installateur à fait, ou pour améliorer sa configuration : il suffit de rechercher les noms de paquets rpms ! par exemple urpmq -y ladspa ! et de les installer !
  • Oui, aussi : par exemple, savoir que arts a un temps de latence qui est configurable permet de répondre à la question : 'pourquoi audacity me marque parfois que le système de son est occupé ?'. Ou encore connaitre fuser -k /dev/dsp
  • En résumé, alsa : "Support efficace de tous les types d'interfaces audio, des cartes sons du consommateur aux interfaces audio multicanales professionnelles. Entièrement modulable. SMP et conception sûre. Bibliothèque de l'espace d'utilisateur pour simplifier l'application programmant et pour fournir la fonctionnalité de niveau plus élevé. Soutien de l'OSS/Free et ancienne api, fournissant la compatibilité binaire pour la plupart des programmes d'OSS/Free. Autorisé sous la GPL et la LGPL. " ...
  • Encore ? Par exemple les fichiers /etc/.asound.names & state ou encore ladspa et ses possibilités… Aussi bien sur le fonctionnement de alsa et de jack ensemble. Enfin la norme midi… Mais la note juste suivante est consacrée à quelques premières applications.
Blog Home

 
Comments: 3 comments ...
 
 
 
Attachments: 21 Attachments by bubar ...
 
 

RSS
EtLeSonII ()
Creator: bubar  Date: 2005/12/21 18:26
Last Author: bubar  Date: 2006/03/28 22:52
Valid XHTML 1.0!