Qu'on se le dise, bien configurer sa distro favorite pour l'audio en realtime (moins de 5-6ms ADC-DAC) est pas des plus aisé.
Surtout quand on a des impreratifs de stabilité, comme pour moi mixer en live un certain nombre d'entrés analogique.
En bon néophite, je pensais qu'installer un kernel patché RT suffisais. Que néni mes amis, c'est le début d'une longue aventure.
Pour résumer la situation, mon objectif est d'obtenir une latence la plus proche possible des 4ms permise par le firewire, avec jackd2, pleins d'applications venant s'y plugger, et sans le moindre Xrun.
Ce poste sera donc régulierement mis a jour en fonction de mon avencement sur le sujet.
Niveau materiel ma config actuelle :
- Core i7 3.4Ghz, 8Go de ram
- Chip firewire VIA VT6315
- Interfaces audio M-audio Profire 2626 & ESI QuataFire 610 & Motu Ultralite MK3 hybrid (non suporté pour l'heure)
Niveau soft :
- Debian Sid, qui a un peu bourlingué
- Gnome 3 (loin des plus light, mais très pratique pour monitorer pleins de vu-mêtres dans differentes fenêtes)
- Kernel 3.12-1 RT (venant des dépots)
- Jackd 1.9.10 & libffado 2.1.9999-2470
Venons en aux fait :
Problématique
Jack, out-the-box avec mon kernel 3.12RT me permet des latences déjà interessantes de l'orde de 10ms entre l'entrée analogique d'une carte, et la sortie de l'autre.
Malheureusement des Xruns surviennent, et principalement des Xruns dû a FFADO, lors de changements de bureau virtuel / alt+tab. Ce qui me pousse a optimiser au mieu priorité des IRQ, timers, et tout ce qui peut jouer.
Outils
$ffado-test (fournis par le paquet ffado-tools) : Permet d'acceder directement au driver, lancer des BusReset quand les interfaces sont plantés par exemple
$ffado-diag (fournis par le paquet ffado-tools) : Check-up de la configuration logiciel pour faire tourner au mieu ffado
$jack_control (fournis par le paquet jackd2) : Permet de controler le serveur jack via dbus, quand celui-ci est lancé via jackdbus. Beaucoup plus d'options sont disponible que via qjactrl, et ca évite de retenir une ligne de commande interminable !
$jack_iodelay (fournis par le paquet jackd2) : Utilitaire de mesure de latence via jack
$realtimeconfigquickscan (script perl) : Check-up des configuration de l'os pour le realtime.
http://wiki.linuxaudio.org/wiki/system_configuration : L'une des docs la plus complète sur le sujet, ce me semble.
Soluces, en vrac
Puredata fait planter Jack a faible latence
ou L'interface graphique de puredata est très lente quand lancé avec Jack
D'après mes tests (tout a fait empiriques, corrigez moi si je me trompe...) il semble que puredata n'aime pas certains combo frame/periode - buffer audio. Solution trouvé : le lancer avec un autre temps de buffer (a +-1ms ça fonctionne...).
Au passage, le nombre de frame/periodes (appelé "Vecteur audio" dans l'interface graphique de puredata) et la frequence d'échantillonage doivent être le même que celui de jack, et plus on demande une faible latence a puredata, plus on risque de Xruns. "Use callback" doit être activé, ce qui n'est visiblement possible que par l'interface graphique. Pour le reste, voila une bonne facon de lancer puredata :
$pd-extended -rt -nosleep -jack -channels 8 -r 96000 -blocksize 512 -audiobuf 6
On lui demande donc là 8 canaux, a 96kHz, 512 frame/periodes et une latence de 6ms. Les options -rt (ordonanceur Temps Réel) et -nosleep (ne pas passer en IDLE, meilleur latence avec du multi-cpu) ne sont pas obligatoires, mais recomandés.