Les (mystérieux) fichiers de configuration et les PlugIns

ALSA peut être configuré pour toutes sortes d'utilisations un peu avancées et possède un système de greffons. Ceux-ci ne sont pas graphiques, c'est à dire que vous n'allez pas cocher tel ou tel greffons, ils sont utilisables/configurable dans les fichiers de configuration d'ALSA par un système d'écriture. Les informations à ce sujet étant relativement rares et pas toujours très claires, nous allons essayer de dégrossir ceci dans ces pages.

Les fichiers de configuration d'ALSA

Avant tout, voyons où se trouvent ces fichiers de configurations et quels sont leurs différents rôles.

Il y a 2 fichiers de configuration pour les pilotes d'ALSA (ses pilotes et ses modules) :

• un fichier pour chaque utilisateur,
• et un fichier pour les réglages globaux du système.

Aucun de ces fichiers n'est indispensable pour qu'ALSA fonctionne correctement, la plupart des applications fonctionneront sans cela. La principale utilisation de ces fichiers est de permettre d'ajouter des fonctionnalités telles que du routage ou de la conversion de fréquence d'échantillonnage.

➡️ Voir également : Informations tirées de http://alsa.opensrc.org/.asoundrc.

Emplacements des fichiers de configuration suivant les distributions :

• Pour TangoStudio, basé sur Ubuntu 10.04, les fichiers de configuration sont :
  • utilisateur simple : /home/olinuxx/.asoundrc,
  • super utilisateur : /root/.asoundrc.

Note : à priori, certains systèmes utilisent, pour les réglages globaux, le fichier /etc/asound.conf.

Principe général

(note : tiré/traduit/adapté de http://alsa.opensrc.org/index.php/Plugin_Documentation qui donne les bases de compréhension du fichier .asoundrc)



Les greffons sont utilisés pour créer des périphériques virtuels qui pourront être utilisés de la même façon que les périphériques matériels par vos applications. Il faut noter que les greffons créent des latences supplémentaires du fait des processus qu'ils déploient. Par exemple, si vous créez un greffon de ré-échantillonnage, ceci utilisera pas mal votre processeur et pourra ralentir votre système.

Les périphériques virtuels sont créés dans les fichiers de configuration d'ALSA (voir le chapitre ci-dessus).

Regardons un squelette basique pour définir un périphérique virtuel :

pcm.UNNOM {
    type TYPEDEGREFFON
    slave {
        pcm NOMDESCLAVE
    }
}

Ceci crée un nouveau périphérique virtuel :

• du nom de UNNOM,
  • UN_NOM peut être n'importe quel nom simple. C'est le nom que vous utiliserez pour faire référence à ce périphérique plus tard. Il y a plusieurs noms de périphériques virtuels pré-définis, comme default et dmix,
• d'un type TYPEDEGREFFON,
  • TYPE_DE_GREFFON est l'un des noms listés dans la documentation officielle. Par exemple : dmix (note : dmix peut être un type de greffon ou un périphérique virtuel prédéfini), jack, et linear,
• qui fait suivre sa sortie dans un autre périphérique (virtuel ou matériel) du nom de NOMDESCLAVE,
  • NOM_D_ESCLAVE est le nom d'un autre périphérique virtuel ou d'une chaine qui décrit un périphérique matériel. Pour spécifier le premier périphérique de la première carte, utilisez "hw:0,0" (avec les quotes).

Router un flux ALSA vers JACK

Installation

Le PlugIn JACK est distribué dans le paquet alsa-lib de la distribution d'ALSA (il peut avoir un nom différent de alsa-lib, par exemple libasound2 ou libasound2-plugins chez Ubuntu). Pour savoir s'il est installé, vous pouvez par exemple rechercher le fichier libasound_module_pcm_jack.so sur votre système. Sinon, il se compile très facilement à la main. Bien entendu, il faut que JACK et ALSA soient installés.

Configuration

La configuration suivante crée un périphérique virtuel appelé "jackplug" qui crée une connection à JACK lorsqu'on l'utilise.

pcm.jackplug {
    type plug
    slave { pcm "jack" }
}

pcm.jack {
    type jack
    playback_ports {
       0 alsa_pcm:playback_1
       1 alsa_pcm:playback_2
   }
    capture_ports {
       0 alsa_pcm:capture_1
       1 alsa_pcm:capture_2
    }
}
 

Test

Si on souhaite utiliser ce périphérique virtuel comme périphérique par défaut on peut l'indiquer dans .asoundrc de la façon suivante :

pcm.!default {
    type plug
    slave { pcm "jack" }
}

Il n'est alors plus nécessaire de spécifier pour chaque application le périphérique à utiliser.

Attention toutefois, j'ai rencontré des problèmes avec certaines application, notamment mplayer qui se bloque.

Faire du ré échantillonnage

à compléter... ...on peut aussi utiliser Audacity ou Rezound.

Faire du mixage software

Beaucoup de cartes son n'offrent pas de mixage hardware (=mixage matériel) et ne permettent donc pas d'être utilisées simultanément par plusieurs applications. On doit alors recourir au mixage software (=mixage logiciel) : la partie mixage sera effectuée par un logiciel qui aura l'accès exclusif à la carte.

Sous Linux, les serveurs son habituels offrent ces possibilités de mixage logiciel mais, pour des raisons de latence, on préfèrera l'utilisation de JACK.

Un PlugIn a été développé afin d'offrir nativement cette possibilité de mixage logiciel dans ALSA : il s'agit de Dmix (pour "direct mixing").

Il peut être combiné en tant que PlugIn ALSA par défaut, offrant en théorie cette possibilité de mixage logiciel à toute application compatible ALSA. Dans la pratique, seules certaines applications en profitent !

plughw

"plughw" est une sorte d'abstraction qui étend "hw" et permet d'utiliser sa carte avec plus d'applications. Le "problème" de certaines cartes professionnelles est que leur conception déroute certains logiciels qui s'attendent à trouver une bête sortie stéréo en 44.1khz/16bit. "plughw" permet donc de présenter à ces logiciels une sortie virtuelle standard.

Notes

Sous certains distributions (ex: Gentoo), il y a un paquet alsa-plugins qu'il faut installer.


Ressources : la documentation officielle des plugins d'ALSA : http://www.alsa-project.org/alsa-doc/alsa-lib/pcm_plugins.html.