Chibi-nah::blog

Pour cette série d'articles orientés MAO, commençons par la base.

Sous GNU/Linux, disons le franchement, au niveau du son, c'est le bordel.

Source de l'image : Mike Melanson, http://blogs.adobe.com/penguin.swf/

Au niveau des pilotes.

Pour résumer, il y a trois "pilotes" [1].

• Le plus ancien (1992) étant OSS : Open Sound System. Utilisant le principe de base UNIX (tout est fichier) via /dev/dsp, il était facile pour un développeur de jouer des sons. Cependant, le support matériel était limité, pour jouer plusieurs sons en même temps, il fallait que la carte supporte le mixage matériel, etc. Suite à un changement de licence (passage vers une licence privatrice pour pouvoir supporter plus de matériel) [2], il a été remplacé par (suspense).


• ALSA, Advanced Linux Sound Architecture, le "pilote" actuel (depuis 1998), remplaçant OSS. Fournissant à la fois le support matériel (donc de bas niveau) et un ensemble de ressource pour les développeurs (API), il a la réputation (réelle) d'être plus difficile à programmer qu'OSS.


• OSS4. 4Front Technologies (ayant sponsorisé le développement de XMMS et ayant embauché le développeur initiel d'OSS) propose OSS v4 (version 4) sous licence GNU/GPL, et donc de nouveau libre (depuis 2007) [2].

Inutile de préciser que l'on a (encore, comme d'habitude dans le monde merveilleux de l'OpenSource), une guerre de clochers entre les défenseurs d'OSS (simple à programmer, meilleur son qu'alsa parce que code plus simple) et les défenseurs d'ALSA (OSS : libre puis proprio puis libre, ça sera quoi après ? proprio ?).

Au niveau logiciel

Préparez le popcorn, c'est bien pire.

Chaque projet majeur a (ou a eu) sa propre solution pour palier les problèmes d'OSS/ALSA. On les appelle "serveur de son". Je n'aborderai donc que les plus gros.

• KDE a(vait) sa propre surcouche par dessus OSS : aRts, pour analog Real time synthesizer, qui comme son nom l'indique (ou pas), permet de mixer plusieurs sources audio avant de l'envoyer vers la carte son. Officiellement abandonné depuis 2004.


• KDE (à partir de la version 4) utilise désormais Phonon, qui est un framework multimédia, remplaçant aRts, et devant être autonome, afin de ne pas dépendre d'autres ressources (comme xine, gstreamer, vaste sujet également).


• Enlightenment avait son serveur de son : ESD Enlightenment Sound Daemon. Gnome a également utilisé ESD. Gérant le mixage de manière logicielle, ce serveur de son avait également la possibilité d'envoyer du son à travers le réseau local (par exemple, le son joué sur un PC portable pouvait être transmis à une chaîne hi-fi branchée sur un pc fixe, les deux ayant ESD de configuré et fonctionnel). ESD n'est plus utilisé de nos jours.


• Pulse Audio (anciennement Polipaudio, datant de 2004). Il s'agit du serveur de son quasiment le plus répandu actuellement, et ce, malgré les polémiques (liées aux prises de position de son développeur, je n'entrerais pas dans les détails, ça finira en troll… regardez systemd [3]). Pulse Audio est le successeur d'ESD, supportant en plus le mixage audio par application (comme sous Windows Vista et successeurs), gérant les oreillettes Bluetooth (A2DP…), etc etc etc. Il souffre toutefois de problème de latence (à priori résolu dans les dernières versions), et de charge CPU pouvant être relativement élevée (le ré-échantillonnage à la volée pour l'encodage audio étant consommateur de ressource) [4]. Lors de son premier déploiement majeur, ce serveur de son avait tendance à casser toute la chaîne audio [5].


• Jack, pour Jack Audio Connection Kit (donc rien à voir avec Jack, une chanson de MagoYond [6]), est un serveur de son temps réel et a faible latence, et est devenu de fait (de facto) LE serveur de son pour l'audio professionnelle (et donc, pour le home studio). Depuis la version 2, jack est multiplateforme (GNU/Linux, Mac OS X, Windows, Solaris, iOS, et *BSD).

Pour résumer

Contentons nous d'une solution qui fonctionne, c'est à dire le duo jack + alsa. Cela limitera les couches logicielles à traverser.

Source de l'image : http://tuxradar.com/content/how-it-works-linux-audio-explained

Sur la plupart des distributions GNU/Linux, jack est disponible dans les dépots (chercher jackd ou jack2).

KXStudio

http://kxstudio.sourceforge.net/

Sous Debian et dérivées, Ubuntu et dérivées, et ArchLinux, il existe un projet intitulé KXStudio, et comprenant tout ce qui est nécessaire pour faire de la MAO, que cela soit au niveau des applications ou des plugins. KXStudio propose également un dépot "non-free", pour les logiciels non libre. On y retrouve (entres autres) Reaper (en version Windows, packagé pour fonctionner sous GNU/Linux via wine), Renoise, le support des plugins VST…
http://kxstudio.sourceforge.net/Documentation:Manual:kxstudio_and_free_software

À noter, KXStudio peut également être installé de manière autonome (distribution Linux).

Pour l'installer sur sa Debian ou Ubuntu, il suffit de suivre les instructions de la documentation de KXStudio (ajout de dépot, ajout de l'architecture i386 sur une machine x64…)

Conseil important : pour éviter les prises de tête, n'installez pas (ou désactivez) pulse-audio. Pulse-audio prend la main de manière exclusive (pour lui tout seul) la ou les cartes sons qu'il détecte. S'il est démarré, jack ne pourra pas fonctionner. Regardez le schéma un peu plus haut et vous comprendrez facilement pourquoi.

Pour bien commencer

si on n'installe pas les meta-paquets (qui installent tout un tas de logiciel, par catégorie), il vaut mieux avoir au minimum :

• Cadence. Cette application permet la configuration et le démarrage/arrêt de jack. Il y a également la gestion des ponts entre alsa et jack.

• Catia. Cette application permet de faire les routages audio et midi de manière simple et visuelle.

• wine-rt. Cette application permet de faire fonctionner les applications Windows sous GNU/Linux ; avec, certes, plus ou moins de succès, suivant l'utilisation des ressources sous Windows (API, tout ça). Ici, il faut noter le suffixe "-rt". Il s'agit d'une version modifiée (patchée) de wine, pour fonctionner en mode "temps réel", afin de réduire au maximum la latence.

• FeSTige. Cette application est une interface graphique au dessus de fst. Fst étant une application capable de faire fonctionner les plugins VST via wine-rt. Les plugins apparaissent alors comme des applications sous Catia, et on peut alors les relier entre eux, piloter des vsti via un clavier maître ou un arpégiateur, etc… À noter, Festige est surtout utile pour jouer en live, ou pour tester les plugins de manière autonome (donc, pas dans un DAW).
  
  À noter aussi, FeSTige permet également de gérer les plugins VST via dssi-VST. Dans ce cas, le midi passe via alsa et non via jack, et ne permet pas l'intégration via ladish et ne supporte pas non plus les presets. Ces deux points seront expliqués dans des prochains articles.
• Audacity Le logiciel d'édition de son multi-plateforme. Il est à Cubase ce que le bloc-note est à Word. Il permet seulement l'édition et l'application d'effets (pas en temps réel, et en mode destructif), ne gère pas le midi. Bref, ce n'est pas un Daw. Il est pratique pour faire de l'enregistrement de source sonore, de retoucher vite-fait des fichiers audio (découpage, trim, application d'un coupe bas, ou encodage dans un autre format…)
  
• Audacious (j'en vois qui rigolent au fond). Il s'agit d'une reprise (fork) de Beep Media Player, lui même réécriture de XMMS (X MultiMedia Sound) en gtk2, lui même clone de Winamp, mais pour Unix. Pourquoi parler de ce lecteur ? Tout simplement parce qu'il supporte jack comme sortie audio. On peut également, et ce, jusqu'aux versions antérieures à la 3.5, l'utiliser comme lecteur midi, et router le flux vers un périphérique midi externe (comme un expandeur), ou d'utiliser fluidsynth pour avoir une synthèse midi presque aussi catastrophique que la synthèse midi sous Windows [7]
  

Conclusion

Cet article n'a fait que survoler une toute petite partie de la MAO sous GNU/Linux.

J'ai préféré commencer par aborder une partie de l'historique (pourquoi on en est là), puis à indiquer quelques logiciels pour commencer à expérimenter.

Le prochain article présentera plutôt un cas concret, comme par exemple, un synthétiseur avec un plugin de reverb et un analyseur de spectre ?

---

1 : techniquement, seulement 2, si on considère OSS et OSSv4 comme étant un seul "pilote"
2 : http://en.wikipedia.org/wiki/Open_Sound_System#Free.2C_proprietary.2C_free
3 : Les deux projets étant créés par la même personne, je ne lancerai donc aucun troll.
4 : Pour des raisons de débit, une oreillette ou un casque bluetooth ne supporte pas le format PCM. Il faut donc utiliser un codec (à la MP3, mais encore plus compressé) pour envoyer le flux audio à travers le bluetooth. Cela me fait doucement rigoler ceux qui "écoutent" de la musique avec un casque Beats en Bluetooth, double combo pour la qualité \o/ (ceci étant un troll, bien entendu).
5 : Bien entendu, si cela ne marche pas, c'est de la faute d'Ubuntu, pas du développeur…
6 : http://magoyond.com/,
7 : Pour avoir un VRAI Roland Sound Canvas (un SC55 de première génération), je confirme : la synthèse Windows, bien qu'étant basée sur un Sound Canvas, ne fait clairement pas honneur. Les sonorités "ressemblent" de loin par rapport au vrai, mais sonnent très mal (comme si on avait échantillonné les instruments sur 4 bits à 11 000Hz). Je posterai quelques exemples comparatifs dans un prochain article.