Et le Son ? (suite III)

Dans de précédents billets de mon blog, j' ai abordé les bases de l' architecture & de la gestion du son sous gnu-linux. La suite logique est de voir comment se débarrasser d' arts sous kde, comment améliorer le temps de réponse entre kernel/système/applications/instruments connectés à la machine et quel est le meilleur choix applicatif pour cela … On l' a vue : l' architecture du son avec gnu/linux est à la fois source de liberté de choix mais également source de contraintes d' utilisation liée à ces choix.

Rappels

L' architecture rencontrée après une installation :

Cette solution est simple, souple et donne des résultats satisfaisants. ARTS, mixeur de haut-niveau du bureau KDE étant en charge d' assurer un fonctionnement commun d' applications et un mixage du son en sortie entre elles. De plus, par un simple click de configuration il va pouvoir rétrocéder l' accés à ALSA très rapidement (il est fortement recommandé de descendre la valeur par défaut à 2 secondes). Dès qu' une application cesse d' utiliser ARTS, celui-ci libère son accès, et une autre application qui ne possède pas de plugin pour lui et ne veut comprendre que ALSA peut alors attaquée ce dernier directement sans soucis. Lorsque cette application à finie, et que l' on lance une autre demandant ARTS, celui-ci se remet en route immédiatement. En plus il existe un "soundwrapper" qui permet de forcer une redirection du flux vers arts. Par exemple en lançant

soundwrapper audacious

L' architecture par défaut, mais plus complète

Cette image montre un ensemble plus complet, mais toujours l' ensemble rencontré par défaut lors d' une installation. Le groupe "tremulous+xmms/arts+mplayer/arts+aucious/forcé+ktts/arts" peut fonctionner ensemble et nous entendre tout les sons de toutes ces applications ensemble. Le groupe "audacity+sweep+rezound+lmms" peut fonctionner en toute transparence grâce à la retrocession immédiate de arts sur alsa. Ces applications peuvent être lancées quant arts à rétrocédé son accès, elles fonctionneront immédiatement. Mais elles ne peuvent pas fonctionner simultanément avec xmms/arts par exemple et elle ne peuvent pas fonctionner en même temps entre elles. Chacune d' elles nécessitent un accès exclusif à ALSA.

Malgrès ses contraintes, ce système ci dessus est celui permettant d' avoir un bureau parfaitement multimédia. tout en conservant toutes les libertés de l' architecture de son de linux. selon les besoins, on utilise telle ou telle application, dans la meilleure transparence et la plus grande facilité. nul doute que le remplaçant annoncé pour arts conservera ce système de rétrocession automatique.

Le cas Dmix

Dmix est un mixeur intégré à alsa. Il permet de pouvoir mixer entre elles des applications alsa, lorsque la carte son ne le permet directement par son harware. C' est la solution généralement retenu pour faire sauter tout autre mixeur, comme arts. En utilisant Dmix nous pourrons donc entendre des sons joués en même temps par toutes les applications attaquant alsa. Lancer alsaplayer avec l' argument pour Dmix, et on peut entendre la musique joué par celui-ci alors que jack est déjà connecté (voir plus bas pour Jack) un exemple de commande est

alsaplayer -o alsa -d plug:dmix musique.ogg

Notion de latence et traitement du signal audio

Latence

La latence c' est grosso modo le temps nécessaire au matériel informatique pour traiter un signal audio qu' il reçoit. La latence est audible quant par exemple on branche une guitare ou un piano sur l' ordinateur et que le son produit est décalé. Décalé entre le son réel qui sort du piano ou de la guitare et celui qui sort des enceintes de l' ordinateur.

La notion de "tampon" (buffer) se retrouve partout, à tout les niveaux : même purement matériel. Une carte son à une latence en entrée par exemple. C' est à dire que pendant que un tampon est lu, un autre est rempli. En terme informatique on appelle les IRQ (attention ce terme n' est ni spécifique ni parfaitement résumé et défini ici) l' ordonnancement en entrée et en sortie. L' image suivante montre comment on peut présenter cela le plus simplement possible.

Et on retrouve cela à tout les niveaux. Sous différentes formes et appellations selon le contexte, mais toujours selon le même principe.

Traitement sur un bureau multimédia courant

Des temps de décalage sont également audibles si l' ordinateur est très occupé à faire quelque chose et doit dans le même temps produire un son, une musique à écoutée. On entendra alors une série de blancs successifs qui hacheront le morceau et rendront son écoute bien inconfortable. Sur un bureau multimédia la solution courante est d' avoir un "tampon" audio : c' est à dire une "mémoire", une "swap" sur laquelle l' ordinateur va stocker les informations avant de les restituer sur les haut-parleurs, la sortie standart. Cela permet un grand confort. Par exemple arts peut être configuré pour agrandir son tampon audio, ce qui va résoudre ces "blancs" lors de lectures sur de petits ordinateurs ou sur des machines très occupées à faire autre chose.

Mais si cette solution convient tout à fait pour le bureau multimédia de Mr-tout-le-monde, il est logique qu' il soit en décalage avec une demande de jouer un son de guitare ou de piano pour un enregistrement studio… Si le tampon est élévé, la sortie du traitement du signal n' en sera que plus décalé et les musiciens vous avoir toutes les difficultés du monde à entendre ce qu' ils jouent vraiment. Pour grossir un exemple : imaginez que vous branchiez votre guitare sur l' ordinateur, qu' un ami branche sa basse et que chacun soit munis d' un casque reliés à ce même ordinateur : le but étant de jouer ensemble pour enregistrer un morceau et d' avoir le retour dans son casque de ce que l' on joue. Grossissons le résultat : je gratte une corde et mon ami aussi sur sa basse : j ai un décalage de 1 seconde dans mon casque sur ce que je joue (pas bon) et dans le même temps j' entends ce que joue mon ami avec un décalage de 2 secondes (pas bon non plus)… Il va devenir très… heu… sportif de jouer dans ces conditions.

Notion de gestion des process dans le système

Un système informatique c' est tout plein de trucs partout qui tournent en même temps :shock: Considérons le système informatique comme un ensemble de process permettant de gérer du matériel. Cet ensemble de process nécessite de l' ordre. Deux process se tapant dessus pour obtenir un accès rapide et élevé sur le processeur central pourraient faire freeze tout les autres. Il y a beaucoup de gestion différentes permettant de mettre de l' ordre dans tout cela. Par exemple sur une Mandriva, lancer une compilation ne pose aucun soucis par défaut! Parceque le process de compilation reçoit une attribution de basse priorité : il est donc aisé et agréable de faire du développement et de la compilation sur un tel système : On peut continuer sereinement une autre tâche pendant que la première est en train d' être compilée. C' est qu on appelle le "nice" d' un process. Nice est une commande avec un vocabulaire spécifique allant de -20 (la plus haute priorité) à +19 (la plus basse priorité). Et c' est l' ordre général des "nice" des process qui va réguler cela ensemble. Exemple grossi : un process ayant un nice de -10 tournant parmis plein de process ayant un "nice" de 0 sera prioritaire. Si un autre process est lancé, mais avec un "nice" de -15, il sera prioritaire sur tout les autres. Et celui avec -10 restera prioritaire sur ceux ayant 0. C' est donc un système de régulation du travail fonctionnement sur un ensemble de process dont chacun à un attribut personnel servant à le "catégorisé" dans cet ensemble.

Notion de latence dans le noyau

Le noyau linux est taillé par défaut pour la sécurité pleine et entière du système. Il est possible avec Linux d' aller encore bien au-delà (rsbac / grsecurity ; selinux ; … etc). Par défaut tout les process doivent passer par d' énormes 'commissariats' qui se chargeront de vérifier leurs demandes puis les laisseront accéder au matériel, par exemple la mémoire vive, et en plus selon des procédures strictes de qu' ils ont le droit de faire ou pas, pour cet accès.

Ces systèmes sont logiquement sources de latence. Mais il ne sera pas nécessaires de les mettre de côté (contrairement à d' autres o.s.). Nous pouvons conserver ces sécurités pour l' ensemble du système tout en autorisant un accès privilégié pour certains process, et uniquement ceux là. Tout en restant dans un cadre Linux (gestion mémoire vive, etc..)

C' est la notion de "low-latency" (faible latence). Pour bénéficier de cette configuration il faut recompiler le noyau avec cette option. Ensuite, il faut renseigner le système en lui disant quoi, qui et comment pourra en bénéficier.

Mandriva & la Musique Assistée par Ordinateur

Mandriva et la faible latence

Le système Mandriva va nous éviter l' étape la plus laborieuse, la plus difficile pour un débutant ou un utilisateur ne voulant pas en savoir plus. En effet, Mandriva fournit par défaut tout un ensemble de kernels précompilés. Pour en avoir la liste tapez simplement

urpmq -y kernel

Le bon kernel

Installer simplement celui qui convient à votre type de machine et tout ira bien. Par exemple

urpmi kernel-multimedia-desktop-latest kernel-multimedia-source-latest

La bonne configuration du système Mandriva

Tout est d' ores et déjà prêt pour le noyau (!!) Il nous reste un point à faire manuellement : choisir nous-même qui aura droit à quoi avec ces nouvelles fonctions. Il est important qu' on fasse cela nous même, car sans même l' objectif de tout savoir, il est important que nous sachions au moins qu' il s' agit de sécurité. Sans donc entrer dans des détails, voici ce qu' il faut faire :

• Charger le module temps-réel à chaque boot

echo "realtime mlock=1 gid=81" >> /etc/modprobe.conf

echo "realtime" >> /etc/modprobe.preload

• S' assurer que les utilisateurs soient dans le bon groupe

userdrake

Permettre l' utilisation du temps réel

Au groupe audio par le module de sécurité "pam" : Editez le fichier

/etc/security/limits.conf

@audio - rtprio 99
@audio - nice -15
@audio - memlock 250000

-> notez que la valeur 250000 pour "memelock" devra être ajustée à votre système. La bonne valeur est de 30 à 60% de la mémoire vive disponible sur votre machine (ici une machine ayant 512MO, je ai attribué 250MO). -> notez que vous pouvez bien entendu ajuster la valeur "nice" -> notez que le vocabulaire de la valeur rtprio va de 1 à 100. 99 est une très bonne valeur, celle conseillé ici. -> notez que le sigle - entre @audio et nice par exemple, est bien une commande : nous voulons à la fois soft ET hard. Il est possible d' écrire soft ou hard.

JACK, le roi

L' ensemble de votre système est prêt : il est taillé à la mesure d' un studio de mixage et d' enregistrement digne de ce nom. Le noyau est le bon, la configuration du système est prête, l' audio sera "très faible latence" et la sécurité est conservée.

La meilleure solution est JACK. Ne vous fié pas à son nom ou à son logo, il ne s' agit pas d' un système pour les entrées jack… Il s' agit de beaucoup plus que cela. Jack est un serveur de son et un mixeur. Jack est LA solution dans un cadre MAO. Installons le ainsi qu' une petite suite applicatives spécifiques

urpmi jack jack-rack jackasyn jackbeat jackeq jackit jackit-example-clients jackmix

KDE, le bureau

Maintenant nous allons nous 'débarrasser' de ARTS. Car il ne convient pas pour une utilisation dans le cadre "faible latence". On le voit dans l' image ci dessus, KDE est est au poil : contrairement aux autres bureaux, il permet une plus grande souplesse dans le choix de l' utilisation de diverses solutions de sons pour tout son ensemble applicatif! Menu k -> système -> configuration -> kde -> système de son -> Choississez et validez "jack". On peut espérer beaucoup de son remplçant, nommé phonon, on verra bien à l' usage. En attendant, redirigeons tout cela vers jack. Ha si on pouvait avoir un vrai kde -arts et +jack directement complètement, quel bonheur...

En plus, une superbe application à été écrite en QT pour gérer JACK facilement. Il s' agit de Qjackcontrol. Installez là, ainsi que son complément, illico :

urpmi qjackconnect qjackctl

Configurons le : cliquez sur setup et cocher la case "temps-réel', puis placer le "sample rate" sur 48000 (...). Ne le démarrez pas maintenant, mais configurer le pour que lors de son lancement, il lance jack lui-même. Remarquez qu' il vient avec un "dock" dans la "boite à miniatures" superbe et très très pratique.

Notez que dans la première image, jack à un fond rouge : c' est qu' il est pas content, il y a eu un xrun alsa… c' est normal lors de son lancement, ça l' est beaucoup moins après. Les xrun, sur un sytème bien configuré ne doivent être du qu' à uniquement kde … Sur la seconde image, jack est content : branché, en temps réel et en train de bosser… Maintenant configurer KDE pour qu' il démarre qjackcontrol à chaque session, coooool. (note : il peut arriver que selon le nombre d' appli à démarrer à l' ouverture de session de kde -votre configuration- que qjackcontrol ne se lance pas premier et ne démarre donc pas assez tôt jack. Kde affiche une boite de dialogue disant que "le système de son blabla pas de son blabla" -> ce n' est rien, lancer la conf du son de kde et re-valider/appliquer jack : tout marche illico)

Limitations ?

Certains logiciels, pour d' obscures raisons ne prennent pas en charge JACK comme sortie audio : ignorez les. Dé-installez les, même ! On regrettera que des logiciels comme SWEEP n' est pas jack dans leur config. Ou encore Amarok (mais pour ce dernier cela ne devrait tarder je pense...). Pour ces logiciels que l' on aime bien malgrès tout et que l' on souhaite garder il suffit d' appliquer la même méthode que celle décrite en début d' article pour arts, mais pour jack : grâce à son dock, il est facile de le controller et de l' arrêter si on veut faire joujou avec amarok ou retravailler un morceau de musique avec Sweep. Néanmoins, on le voit sur l' image du dessus, les limitations sont bien moins nombreuses et uniquement dues par certains logiciels n' étant pas (encore) prêt pour JACK.

Le nombre de possibilités valides de mixage est bien plus important avec JACK.

Suite de Logiciels tendant au studio professionnel

Liste non-exhaustive. Mais déjà, tous les maîtriser va vous donner du plaisir, c' est certain! Comme simple lecteur, le bon vieux XMMS plugin jack est parfait : petit, rapide, il ne consomme rien en ressource. Pour la vidéo, privilégiez bien entendu toutes les solutions basées sur MPLAYER. Tous fonctionneront avec JACK, un simple coup dans leur configuration et tout est OK.

Conclusion

Vous avez dorénavant devant vous un système à très faible latence pour le traitement du signal audionumérique. Du kernel jusqu' à l' application de bureau, en passant par une bonne configuration du système pour autoriser de simple "users" du groupe audio à attaqer le matériel audio en temps réel et, en plus, tout le bureau KDE sous jack. Vous pouvez mettre au défi sans soucis un osX intel de même puissance que votre pc intel Linux. Il est fort probable que les temps de latence soit meilleur sur votre Linux. Quant à windows, malgrès sa facilité d' utilisation, il reste loin derrière un kernel linux complètement temps-réel. Bon pas de flameware … Mais nous avons maintenant un vrai système M.A.O. faible latence.

Il reste une dernière chose à faire.... Rebooter ! Et oui, nous allons maintenant changer de kernel (booter sur le kernel-multimédia). Ce boot aura pour effet de prendre également la nouvelle configuration de PAM. Dès le prochain reboot, tout est ok de A à Z : faible latence audio sur le kernel, nouveau serveur jack, bureau kde sous jack, droit pour les appiclications simples "users".

Et quant on visualise l' image suivante, c' est que vraiment, tout est parfait : pas de Xrun venant de alsa depuis le lancement de jackd, on est en temps réel et jack mixe tout

Liens divers (en complétion actuellement)

JACK : http://jack.sourceforge.net/ ARDOUR : http://www.ardour.org ZYNADDSUBFX : http://zynaddsubfx.sourceforge.net ROSEGARDEN : http://rosegarden.sourceforge.net LMMS : http://lmms.sourceforge.net HYDROGEN : http://www.hydrogen-music.org MUSE : http://muse-sequencer.org/ AND MUCH MORE :)

Pour ceux souhaitant aller plus loin, dans le kernel complètement temps-réel par exemple, ils pourront consulter la documentation que j' ai écrite pour le site LINUXMAO : http://www.linuxmao.org/tikiwiki/tiki-index.php?page=Mandriva (site par ailleurs excellent en tout points)

Remerciements :

• Tout les gnous de la terre bien sûr

• Mandriva pour nous permettra tout cela si facilement
• Linuxmao, le site, pour exister et leurs docs, leurs traductions
• kerneltrap, pour les archives de docs sur le temps-réel
• Enfin, une mention spéciale pour Couriousous qui m' a guidé, après un premier succès perso, à réaliser un vrai et complet kernel temps-réel.

Blog Home