Introduction

Certains producteurs / musiciens / etc utilisent linux pour leur travail. Il se peut qu'ils aient construit un PC entièrement dédié à leur production, où le serveur Jack Audio Connection Kit tourne de façon permanente. En tant que musicien-producteur moi-même, je ne désire pas d'autres couches son intermédiaires entre JACK et le niveau matériel (piloté par ALSA dans mon cas) du genre PulseAudioou autre. En effet, je possède une carte son pro RME HDSP + Multiface II. Le pilotage de l'interface de mixage de cette carte ne se range pas dans le cas générique qu'ALSA fournit pour la majorité des cartes du genre interne (Intel HDA, etc). D'une part, seul le logiciel spécial de mixage TotalMix (ou hdspmixer en linuxien) allié à Jack me permet d'utiliser cette carte sous toutes ces coutures. Cela a comme inconvénient que les logiciels ou applications non "jackifiés" ne peuvent rejoindre l' environnent très flexible et fiable fournit par le graphe audio de Jack. D'autre part, je ne souhaite pas recourir à ma carte son interne (l' "infâme" puce Intel HDA 🙀 ) que je garde constamment 'off' (config niveau BIOS).

Dans ce cas, comment peut-on établir un pont permanent entre Jack et les applications non jackifiées ? Je recherchais une solution du type 'client jack permanent' (à la fois playback et capture). Il y a un 'plugin' ALSA-jack mais malheureusement, ce n'est pas une solution pour plusieurs raisons:
- le client n'apparaît dans le graphe jack que lorsque l'application ALSA joue quelque chose et disparaît aussitôt après
- ce plugin n'a pas été mis à jour depuis longtemps et est très instable.
En bref, il n'est pas à la hauteur des propriétés désirées (permanence du pont, etc).

Ce n'est que récemment, alors que je faisais "mumuse" avec la carte virtuelle ALSA-Loopback que l'idée d'un pont permanent ALSA-vers-Jack m'est revenue. Une sorte de flash, en quelque sorte 😀

Cette page est une adaptation française de Jack and Loopback device as Alsa-to-Jack bridge avec quelques ajouts propres à un wiki général sur l'audio professionnelle.

La carte son virtuelle ALSA-Loopback

La carte virtuelle ALSA-Loopback est comme son nom l'indique un matériel complètement virtuel, une émulation d'une vraie carte son. Elle apparaît dans la liste des cartes son ALSA dès que le module noyau 'snd-aloop' est chargé.

Compiler le module noyau 'snd-aloop' : la méthode douce

Il se peut fortement que le noyau installé par la distro ne contienne pas ce module par défaut. On peut y remédier par la compilation "manuelle" de ce module.



EDIT: J'ai réglé le problème! Voir la mise-à-jour juste après cette section.

À vérifier au préalable que le module 'snd-aloop' n'est pas connu du noyau:



Si 'modinfo' ne reporte rien, alors va falloir compiler la bête. Il faut choper le code source 'alsa-driver' correspondant à la version d'ALSA installé par défaut. Aller soi sur le site http://www.alsa-project.org ou bien utiliser 'sudo apt-get install alsa-source'

Une fois le code source installé, décompressé et désarchivé quelque part sur le disque dur, aller dans le répertoire principal (cd alsa-driver-xxxx) et configurer pour la compilation (ne pas installer le résultat, on fera ça "à la main"):


Note: Si vous avez des erreurs à la compilation, vous pouvez tenter de compiler avec les sources de http://www.alsa-project.org/snapshot/files/ (alsa-driver) qui sont les versions les plus à jour ( règle les problèmes liés au noyau 2.6.36-2.dmz.5-liquorix-amd64 entre autres. )

Note 2:
Si toutefois à la fin de la compilation vous n'aviez pas le fichier snd-aloop.ko dans ./modules, tentez ces deux commandes:


Maintenant, copier le module compiler vers l'installation noyau et enregistrer ses dépendances :



Vérifier que le noyau est maintenant à jour:



Charger le module:


Si ça foire, forcer la main au noyau:


Ensuite, vęrifier:



On garde les options par défaut du module (mais on peut modifier au chargement si on veut, sauf que c'est pas la peine).

Compiler le module noyau 'snd-aloop' : la méthode forte!

OK, si la méthode douce a foiré, on va passer à des choses plus drastiques. On va réinstaller la totalité du pilote ALSA. Alors bien sûr, il va falloir dans ce cas ajouter toutes les cartes sons du système dans la configuration de la compilation. Par exemple, voici mon cas:



Pour savoir de quels pilotes le système a besoin, on peut inspecter le fichier suivant:


et aussi voir à quoi ça correspond pour la compilation:


La dernière commande va reporter toutes les cartes possibles, y en a un paquet 😀

OK, une fois compilé et installé, il va falloir faire repartir ALSA:


sans oublier de charger snd-aloop bien sûr!

Comprendre la structure de la carte virtuelle ALSA-Loopback

Comme son nom l'indique, cette carte virtuelle a pour but de boucler le signal envoyé en sortie vers son entrée. On peut donc collecter le signal d'une application ALSA qui envoie son signal vers la sortie de cette carte à l'entrée de cette même carte 😀 et vice-versa.

Par défaut, cette carte virtuelle est composée de 2 parties, elles-mêmes composées de 8 sous-parties. Par exemple, on peut constater après le chargement du module les choses suivantes:



Les Loopback devices 0 et 1 sont symmétriques, dans le sens où si 0 est utlisé pour la sortie, 1 est automatiquement une entrée et vice-versa.
Les labels ALSA pour ces "devices" sont:


Le principe est assez simple: si un signal est envoyé vers le "sub-device" hw:Loopback,i,n alors ce même signal se retrouve en entrée au sub-device correspondant hw:Loopback,j,n avec
i = [0..1]
j = ~i (c-à-d. si i = 0, j = 1, et vice-versa)
n = [0..7]

Modifier la configuration d'ALSA

Quand ils sont lancés sans paramètre particulier, les programmes ALSA (comme flash dans firefox) utilisent la carte son par défaut qui correspond généralement à la première carte son. Si celle-ci est utlisée par JACK, elle ne sera pas disponible pour ALSA. Il est donc nécessaire de configurer ALSA pour que la permière carte son soit la loopback. JACK utilisera alors la deuxième carte (ou celle appropriée à votre configuration).

Autre avantage, nous pourrons même nous passer complêtement de pulseaudio, mais cela est une autre histoire, très simple sous gentoo, beaucoup plus compliquée avec les distributions basée sur debian ou rpm qui ont gnome comme bureau par défaut.

Exemple de configuration (vous pourrez trouver une description plus détaillée du réglage de "carte par défaut" sur cette page) :
Fichier /etc/modprobe.d/alsa.conf


Les options importantes ici sont index=n et cards_limit=m

Ne pas oublier de mettre à jour la configuration du kernel avec nos modifications. Sous gentoo:


et de relancer ALSA:


Une autre exemple: avec les kernels récents (hum, tout kernel depuis 2 ou 3 ans), une syntaxe plus succincte donne le même résultat:

Fichier /etc/modprobe.d/alsa.conf

Les options de snd-aloop

Le module snd-aloop accepte les options suivantes:


TODO: finir de décrire ces paramètres:

Ces paramètres peuvent être spécifiés dans le fichier de configuration d'ALSA (/etc/modprobe.d/alsa.conf avec une ligne options comme dans les exemples ci-dessous.

* index: obligatoire, détermine l'ordre des cartes sons.
* id: facultatif, un nom.
* enable: facultatif
* pcm_substreams: faclutatif, détermine le nombre de périphériques pcm virtuels de la carte
* pcm_notify: facultatif, ???

Construire un fichier .asoundrc

Ah! le asoundrcien, quelle langue splendide! 😀
J'ai jamais vraiment lu quoi que ce soit à ce sujet mais j'ai du sérieusement le faire pour pouvoir établir ce pont vers Jack. Je vous épargne les quelques noms d'oiseau que j'ai lancé de temps en temps durant l'"apprentissage" ... 😉

Bon, le but est de créer un défaut ALSA basé sur la carte virtuelle Loopback. Comme ça, toutes les applications ALSA utiliseront ce défaut. On a besoin d'un PCM de playback, un PCM de capture, et combiner les deux PCMs en un "plug device" étant capable de full duplex. Noter que le but final est de pouvoir entendre via Jack ce que les applications ALSA jouent, et inversement, enregistrer les entrées Jack dans des applications ALSA.

Voici le fichier .asoundrc dans toute sa gloire :


En résumé, on a défini les PCM suivant:

* ALSA playback = subdevice 0,0
* ALSA capture = subdevice 0,1

* Jack readable client (cloop) = subdevice 1,0 (par symmetrie avec 0,0)
* Jack writable client (ploop) = subdevice 1,1 (par symmetrie avec 0,1)

Tester le nouveau défaut ALSA

Sauver ce fichier dans '$HOME/.asoundrc_loop' et le copier dans $HOME/.asoundrc
A vérifier qu'il ne se trouve pas de fichier .asoundrc existant et déjà utilisé à l'insu de son plein gré 😉

Maintenant, jouer par ex. un fichier audio avec mplayer:


On peut aussi utliser lmms avec ALSA pour tester notre défaut.
Evidemment , on entendra rien encore via Jack!

Le Pont vers Jack

créer des clients jack permanents entre ALSA et Jack

Alors, comme subdevice 0,0 est le PCM ALSA de sortie, le signal sera disponible en entrée vers le PCM 'cloop' défini plus haut (subdevice 1,0). Tout ce qu'on a faire pour le connecter à Jack est d'utiliser alsa_in sur ce PCM 😀
A l'inverse, le PCM ALSA d'entrée (subdevice 0,1) collectera le signal de sortie du subdevice 1,1 ou 'ploop' qu'on a défini plus haut. Tout ce qu'on à faire est d'utiliser alsa_out sur de subdevice. Comme ça, on peut connecter le signal audio d'applications jack à 'ploop' et l'enregistrer dans l'application ALSA 😀
Brillant non ?😎

On peut d'abord tester la chose à partir d'un terminal


et


Connecter le client jack 'cloop' vers les ports de sortie system:playback_xx correspondant aux moniteurs ou casque, rejouer la commande 'mplayer' plus haut ... alors alors ?

Pareil avec skype, connecter system:capture_xx avec le client jack 'ploop' (microphone ou basse ou une session ardour complète!), dans skype, configurer l'audio en sélectionnant "Default" partout (mic, sorties, sonnerie tel). Essayer l'appel test de skype, baragouiner dans le micro ou jouer de la gratte ... alors alors ? 😀

Pour éviter d voir des warnings, nous pouvons ajouter des paramètres, par exemple:

créer un script pour automatiser la création du pont dans Qjackctl

Les clients jack 'cloop' et 'ploop' et leur connection aux ports jack selon les besoins peuvent être créés et initialisés par Qjackctl si on met tout ça dans un script shell, par exemple /usr/local/bin/loop2jack



Noter les paramètres -q 1. Cette option règle la qualité de ré-échantillonage. Dans l'exemple, la configuration est adaptée pour des faibles latences et des petits tampon. Abec -q à 2 ou 3, l'utilisation processeur va grimper.

Sauver le fichier dans /usr/local/bin/loop2jack (avec sudo) et ajouter la permission +x



Dans Qjackctl, allers dans "Options -> Executer après départ du serveur" et ajouter cette ligne



Sauver la config, faire repartir jack. Loop2jack doit executer la création de 'c/ploop' et connecter vers les ports jacks choisis.
Maintenant, essayer la chose en lançant 'skype', ou 'smasher' ou 'lmms', ou juste 'aplay' ou 'arecord'. Alors, ça marche ? 😀
Bien sûr, il y a de la latence vu qu'on a choisi le défaut de buffering des plugins 'dsnoop' et 'dmix'. Et alors ? on s'en fout un peu non ? 😀

Ah oui, j'oubliais: la beauté du truc c'est que si Jack plante comme une m...rde, les applications ALSA continuent à tourner sans s'être aperçues de quoi que ce soit. Y a qu'à refaire partir jack via Qjackctl, et le son revient 😀

Exemple d'asoundrc pour RME Multiface II

Certaines cartes son nécessitent de rajouter des paramètres liés à leur infrastructure matérielle. Ainsi, pour une RME Multiface II nous pourrons avoir le fichier ~/,asoundrc suivant:

Setup alternatif : solution matérielle et logicielle

Thorgal, l'auteur de l'article original en anglais, utilise en plus d'une carte RME, une carte sur la carte mère (Intel HDA) et aussi une webcam USB avec son propre micro. Cela serait un comble de ne pas pouvoir utiliser leurs capacités d'enregistrement d'une façon ou d'une autre, ceci surtout en tenant compte du fait qu'il utilise beaucoup skype.

Rajout de quelques entrées matérielles supplémentaires dans asoundrc

A la place d'utiliser le périphérique loopback pour la capture ALSA capture (toutes les entrées relatives à "ploop" dans les asoundrc précédents), nous pouvons déclarer simplement les entrées matérielles dans asoundrc. Donc, nous enlevons toutes les entrées ploop (y compris les sous-périphériques utilisés pour la capture ALSA et alsa_out, ils sont maintenant inutiles, et nous rajoutons les périphériques matériels PCM de la carte son Intel et de la webcam USB.

Test du nouveau périphérique ALSA en capture

Ceci fut facile à tester. Nous devons être sur que la carte par défaut dans asoundrc utilise pcm capture "usb" comme ci-dessus. Ensuite, nous démarrons skype et le réglons pour qu'il utilise le périphérique "Default" pour tout. Ensuite avec QasMixer ou votre mixeur préféré, nous contrôlons le niveau de capture de la webcam (pourquoi laisser kype le régler?). Ansuite, nous essayons le test d'appel de skype et nous assurons qu'il a bien enregistré votre voix.

Notez que la même chose peut être faite avec la carte Intel HDA ("intel" pcm capture défini dans l'asoundrc précédent) à condition de brancher un micro à son entrée 😊.

Mesure de la latence introduite par le périphérique Loopback