=dblog=

Traduction d’un article de Mstation, c’est un interview de Paul Davis, programmeur, auteur de Ardour (LE système audio direct-to-disk) et Quasimodo (une implémentation du moteur de Csound).

L’URL de l’original est : http://www.mstation.org/pd.php

Paul Davis (programmeur audio sur Linux) nous parle de ses applications…

Paul Davis a beaucoup apporté au monde de l’audio sur Linux. Il a écrit des applications, librairies, et pilotes tels que le pilote ALSA pour la RME Hammerfall. Nous discutons avec lui des particularités de la programmation audio sur Linux.

Mstation : Sachant que je vais poser des questions sur ardour et quasimodo, on pourrait commencer par des conseils pour les gars qui se verraient bien faire de la programmation audio de la plus simple façon. Je dirais, primo apprendre un langage (j’opterai pour le C ou C++), puis lire quelques ouvrages et lire du code.
Tu est d’accord ? Tu recommenderai quels livres ? Je pense que vous pencherez pour le langage C++. Pense tu que les hiérarchie objet sont plus faciles à manier que les librairies de fonctions ?

Paul : En fait, ca depends du genre de programmation audio. Si tu dois écrire des plugins (LADSPA, VST, et autres), alors il suffit probablement d’apprendre un langage (et oui, C/C++ est l’évidence à cause de la vitesse et de l’intégration dans les sytèmes existants), lire n’importe quel livre sur le DSP (la plupart ont du bon), puis se mettre à coder.
De par la façon dont fonctionnent les plugins, tu peux te concentrer a presque 100% sur le(s) algorithme(s) de traitement du signal et expérimenter beaucoup plus facilement que si vous écriviez l’application en entier.

D’un autre coté, si tu dois concevoir du logiciel plus élaboré (par analogie avec les plugins, appelons les “conteneurs"), alors connaître un langage est seulement la moitié du boulot. Tu dois avoir des sérieuses compétences en conception système.
Je ne me suis jamais considéré comme un bon codeur bas niveau - j’utilise encore bc(1) pour faire visualiser les conversions binaire< ->hexa - mais je profite beaucoup de l’expérience que j’ai aquise en concevant puis implémentant des systèmes plus ou moins gros.
Ca ne s’apprend pas dans les livres, mais au cas ou, la bible des programmeurs POO (Programmation Orientée Objet), “Designs Patterns” est un bon point de départ. Pour les systèmes conteneurs, je préfere (evidemment) le C++. Je trouve trés pratique que le compilateur prenne en charge un certain nombre de choses que je devrais faire à la main avec le C, et aussi j’apprécie l’encapsulation et les possibilités des portées public/private que ce langage m’apporte pour coder.

Je ne pense pas que la POO facilite la compréhension du code, mais je trouve qu’il me (en tant qu’auteur) facilite la représentation mentale et la manipulation de sa structure. Je trouve les hiérarchies de classes plus plastiques et malléables, les librairies de fonctions sont applicables quand la sémantique de chaque fonction est simple (par ex. l’API POSIX), mais pas quand il faut englober des mécanismes internes complexes.

En conclusion, il faut vraiment bien comprendre ce qu’implique la programmation temps-réel, avec les fondements du système d’exploitation sur lequel tu travaille. Cela veut dire, pour Linux, bien connaître les relations entre le noyau et une application, l’ordonnancement temps-réel POSIX, l’appel système poll(2), comment fonctionne la mémoire virtuelle et le malloc, ainsi que
pleins d’autres points “avancés".

- Pour les plugins, les débutants peuvent avoir du mal à situer la frontiére entre le plugin et le conteneur … la définition d’un plugin. Je suppose que le meilleur moyen de commencer c’est la documentation LADSPA ou autre.

Dans notre cas, un plugin est un bout de code qui génére ou traite des données (i.e : des échantillons audio). Il ne communique pas avec une interface audio, et avec aucuns de ces trucs compliqués, et ce n’est pas une application complète.
Un conteneur est une application complète, qui dialogue avec une interface audio. Il peut charger des plugins, les organiser en chaine de traitement, et leur permet de fonctionner comme il faut, leur fournissant les données audio obtenus sur l’interface audio,
et repassant le résultat à l’interface. Le conteneur est *largement* plsu complexe qu’un plugin, du moins en pratique. En théorie un plugin peut faire n’importe quoi, mais dans la vraie vie, ils implémentent des choses comme les lignes de delais, modulateurs, équaliseurs multibandes etc.

- Je voulais arriver à dire que la personne avec des connaissances limitées qui pense à écrire un plugin, doit avoir certaines difficultés pour savoir par quoi commencer… mais, je suppose que si elle ne le sait pas encore, alors c’est qu’il faut lire plus.

- ardour et quasimodo - peut tu nous parler de leur génése ?

Pour Quasimodo, le lecteur pourra aller sur http://quasimodo.org/intro.html, qui raconte d’ou vient quasimodo.

Pour Ardour, j’ai commencé à entendre parler de la RME Hammerfall sur diverses listes de diffusion. Ca présentait plutot bien. En Novembre 1999, j’ai d"cidé d’en acheter une, et j’ai commencé à écrire un pilote bas niveau ALSA pour. une fois terminé, il s’est avéré qu’il n’existait pas d’application audio pour Linux capable d’exploiter cette carte, pire, aucune application ne faisait vraiment le poids dans l’environnement studio professionnel/commercial. En fait c’était pire que ca, c’était difficile de trouver un programme qui supporte l’idée de gérer une carte multi-canaux, ou une carte qui travaille en plus de 16 bits.
J’ai décidé de combler ce vide. A cette époque j’étais associé avec un copain qui possédait un studio commercial, et nous voulions y utiliser du Linux et de l’open source. On avait 3 magnétos Alesis M20 ADAT (environ 5K$ pièce), le premier objectif était d’avoir un logiciel pour remplacer les magnétos à bandes. Cet objectif à été atteint assez vite, mais en fait c’était pratiquement inutile dans notre cas, et pour cause, on ne pouvait rien faire d’autre que re-jouer tel quel : aucun éditeur ne pouvait supporter 24 canaux à +500Mb par canal. Aprés que Bill Schottstaedt ait exploré la question avec son éditeur “snd", j’en arrivait à la conclusion qu’on ne pourrait pas insérer ce genre d’opération dans un programme basé sur des interfaces audio 16 bits stéréo.
La portée d’Ardour a évoluée pour prendre en charge tout ce que les systèmes comme ProTools de Digidesign, Sek’d de Samplitude et le système Logic d’Emagic, peuvent faire, et plus si possible.

- Que pense tu de MPEG4 et de choses comme SAOL ? Y a tu déja touché ?

Je n’ai pas d’opinion sur la majeure partie de MPEG4. MPEG-SA (Structured Audio) est la partie qui comprend SAOL.
Je pense que Eric (Scheirer) a fait deux grandes choses avec SAOL : primo, rationaliser le langage des orchestres de Csound, et secundo il a beaucoup oeuvré pour faire entrer SAOL dans le standard MPEG4.
Cela dit, je regrette que le langage choisi soit si démodé - SAOL et Csound (sur certains exemples on s’y méprend) sont basés sur le genre de programmation des années 70 et début 80. En plus de la structure syntaxique, Eric a maintenu une fonctionnalité de Csound qui à mon sens pose problème - la distinction entre les signaux audio et les signaux de contrôle.
Avec la plupart des systèmes hardware que je connais, ce qui est cool c’est de pouvoir mélanger et associer ce genre de signaux puis voir ce que ca donne. Ca peut paraitre bizzare, mais c’est un langage qui va finalement se retrouver gravé dans le silicone et distribué comme composant de matériel destiné au grand public.
L’introduction originale de la distinction audio/controle par Berry Vercoes, était un ajout intelligent aux langages Music N, mais je maintient que c’est une erreur de le garder. Pour être un peut plus positif, j’aurais préféré voir adopter quelquechose comme SuperCollider (langage de James McCartney). Cela dit, SC n’est pas du tout “prés de la machine", et cela aurait violé un des principaux objectifs d’Eric dans la conception de SAOL.

J’ai essayé d’utiliser le compilateur SAOL-vers-C de chez sfront, John Lazzaro et des potes travaillant dessus.
Ce qui à été fait est impressionnant, mais mon opinion est biaisée par les soucis fondamentaux que je peux avoir avec le langage.

- En rapport avec l’écriture du support bi-processeurs pour Quasimodo, y a t’il une grosse différence d’approche lorsque l’on vise un multi-processeur, ou bien est-ce des détails ? Est ce que tu code au niveau du processeur, ou est-ce le compilateur qui s’occupe de ca ?

C’est surtout des détails. il y plusieures choses primordiales à prendre en compte. Le plus significatif étant que tous les kits graphiques basé sur X Window ne sont pas multi-threadés. Ce veut dire qu’il faut faire une choix entre l’approche par verrous explicites sur chaque appel de fonction du kit, et l’approche ou on va s’assurer qu’un seul thread est responsable de ce type d’appels. L’autre souci important est que le thread qui gére les mouvements des données depuis et vers l’interface audio doit être “temps-réel” (au sens d’une deadline d’execution basée sur des battements d’horloge externe).
Dans la pratique, cela revient à éviter le plus possible les appels systèmes, les appels à malloc et free, les opérations de synchronisation (mutexes, variables de condition) etc.

- Quasimodo est il utilisé pour faire de la musique d’ordinateur ‘académique’ ?
Je suis frappé par le fait que en tant que synthétiseur analogique, il peut être utilisé dans tout style de musique.

Pour être franc, Quasimodo n’est actuellement pas utilisé pour produire n’importe quel style. Mais sa conception n’est pas prévue pour être cantonnée à certains styles. Je l’utilise surtout comme processeur d’effets.

- Les gens de l-a-d (la liste de diffusion ‘linux audio developpers’) peuvent témoigner de la difficulté à obtenir des débits suffisamment élevées pour gérer toutes les données. J’ai appris que finalement ca fonctionne maintenant trés bien… pour cela a tu utilisé certaines astuces pour la faible-latence (low-latency hacks), ou bien est ce que tu utilise un noyau standard ?

Les astuces de faible-latence ne sont pas necessaires pour le flux de données, mais sont carréments vitales pour le bon fonctionnement du thread qui gére les entrées-sorties vers l’interface audio.
Maintenant j’utilise toujours un noyau à faible-latence. Je prends un 2.4.0 modifié avec (l’excellent) patch de Andrew Morton, et j’essaye de passer au 2.4.1 qui semble bien meilleur encore. La seule chose qui compte pour les flux de données c’est les performances générales du sous-système d’accés disque. Ca me plait vraiment d’arriver à obtenir des bonnes performances sans utiliser un système de fichiers particulier et avec des format de fichier audio classiques (Ardour travaille actuellement avec le format RIFF/WAVE et les nombres flottants IEEE 32).
Malgré le fait que c’est Linux, la majorité des trucs pour applications audio de Windows ou Mac s’appliquent toujours : fermer les applications inutiles, utiliser un disque dur dédié, etc.
Clea dit, j’ai tendance à faire tourner Ardour en même temps que Netscape, et plusieurs rxvt (terminaux virtuels X distants), xosview, et un énorme processus emacs, et tout va bien (et pourtant j’ai un bi-processeur).

- Quel est le status actuel de l’éditeur inclus ?

Ben, il existe. Mais je pense que le design mérite une refonte drastique. L’orsque j’ai commencé, mes modeles étaient snd et sweep, ou soundforge, des programmes qui fonctionne fondamentalement au niveau de la la forme d’onde. Cela s’avére inadapté lorsqu’il faut “arranger” des morceaux de musique. J’étais contre les concept de “Region” de ProTools (ou “Objets” de Samplitude), mais avec le temps, j’ai fini pas comprendre pourquoi PT (et presque tous les autres) l’utilisent. Ce ne necessitera pas de lourdes modifications du coeur du programme pour rallier ce concept, mais l’IHM va devoir être pas mal modifiée.
Par exemple avec X, c’est pas évident de faire glisser dans tous les sens des régions rectangulaires.

- ProTools est certainement le niveau de fonctionnalités à viser. Il y en a pour plusieures années/hommes de travail ! Ou en êtres vous avec Ardour ?

C’est difficile à dire précisément. Actuellement, on a rien du tout pour l’enregistrement et la lecture MIDI, mais on compte incorporer directement dans Ardour un autre projet GPL, probablement MidiMountain.
Si l’objectif c’est ProTools 5.0 (basé sur TDM) sans le MIDI ni l’automation, Ardour en est à environ 70% du chemin.
Les aspects enregistrement/lecture sont à 99% terminés, la partie mixer à 85%, et les fonctionnalités d’édition en sont à presque 50%. On a aussi des fonctionnalités que PT n’a pas, comme le looping par piste, et une implémentation de la bonne idée de Bill Gribble pour mesurer le clipping. Le travail sur l’automation vient juste de commencer, et il se perd déja dans les
méandres d’un mauvais choix de départ.

- Quel est l’avenir de Ardour ?

J’en arrive à envisager des moyens de gagner de l’argent avec ce travail. Le déroulement de ma procédure de divorce me laisse dans une situation correcte, mais vu l’état de la bourse américaine, mon attitude de départ “ne plus avoir à travailler pour de l’argent” a muté en quelquechose comme “devrait faire des missions de temps en temps pour éviter de fondre mon capital".
C’est un enjeu. Je n’ai pas du tout envie de faire du “support", et j’y connais rien en business models des logiciels sous licence GPL.
C’est interessant. Quand Ardour sera au niveau de protools, des gens vont commencer à s’interesser à lui, les industriels du hardware seront alors plus disposés à prendre en compte les travaux de la communauté audio/midi pour Linux.
Il faudra alors s’orienter vers un modéle rémunérant. Imagine que lorsque tu achète une carte audio, il y ait avec Ardour “gratuitement".
Tout cela, et les autres possibilités doivent s’articuler proprement pour arriver à “terminer” Ardour.

- Merci Paul.