Fachchinesisch 01: Linux-Audio Kauderwelsch und was es bedeutet

Wer mit Linux Audio-Produktionen machen will, muss wohl oder übel auch einmal einen Blick hinter die Kulissen werfen und sich über einige Prozesse, Programme und Daten-/Schnittstellenformate im Klaren sein. Ansonsten stellt sich über kurz oder lang Frust ein, weil nichts so funktioniert wie es soll. Und ein wenig Wissen über die Technik im Verborgenen lässt einen die eigentliche Arbeit souveräner und zielgerichteter erledigen. Das ist so ähnlich wie mit dem Auto fahren: Ich kann zwar keinen Auto-Motor reparieren, weiß aber wie er funktioniert und was nötig ist, um ihn ans Laufen zu bringen und zu halten. Aber keine Angst, ich werde hier ganz bestimmt nicht mit Programm-Code-Schnipseln um mich werfen. Schließlich bin ich ebenso noch ein Newbie in diesem Universum und taste mich langsam immer weiter vor.

Allerdings muss ich zugeben, dass die Beschäftigung damit wahrhaftig nervenaufreibend ist. Die im Netz verfügbaren Quellen – vor allem Foren-Beiträge – widersprechen sich teils, andere wiederum gehen so derbe in die Tiefe, dass einem nach kurzer Zeit die Lust vergeht und man nur noch Bahnhof versteht. Ich will doch nur kurze, knappe Erklärungen haben, um ein grundsätzliches Verständnis zu erlangen. Eine pragmatische Sicht auf die Dinge ist das, was ich brauche. Ich will Musik machen und keine kryptischen Grundsatz-Artikel studieren, die mich in meinem Tun aufhalten. Hinzu kommt als zusätzliche Schikane, dass auf Linux-Ebene verschiedene Audio-Verwaltungs-Programme parallel nebeneinander existieren, bei denen einem leicht schwindelig wird und ich als Endanwender am Schluss mehr rat- und hilflos davor stehe, als souverän und wissend. Das ist eben der Preis eines offenen Systems in dem jeder sein ganz eigenes Süppchen kochen kann und sei es noch so überflüssig.

Also echt, auf diese Weise wird das Interesse an dieser Materie nur allzu leicht verleidet und um die Ecke lacht einen höhnisch die Nerd-Fratze an, die mich als Normal-User aus diesem vermeintlich elitären Club ausschließt. Aber es nützt alles nichts. Schließlich will ich und auch Ihr etwas mehr wissen. Arschbacken zusammenkneifen und durch, lautet also die Devise, wobei ich hoffe, daß das, was ich hier zusammentrage soweit auch richtig ist. Sollte das hier dann doch ein Eingeweihter zu Gesicht bekommen und Fehler entdecken, wäre ich sehr dankbar für entsprechende Korrekturen. So, genug jetzt geschwafelt und los geht’s. Folgt mir ins Kabinett der Linux-Audio-Prozesse:

Windows- und Mac-User werden bei Begriffen wie ASIO, WDM, Core Audio, VST, DirectX, AU, RTAS, AAX wissend lächeln, dabei mit dem Kopf nicken und sie sogleich in die Kategorie der Audio-Treiber und –Schnittstellenformate einsortieren. Das Gleiche gibt’s, wen sollte es wirklich wundern, auch in Linux. Nur dort ist das alles etwas anders sortiert und heißt auch anders. Im Nachfolgenden werde ich jetzt einfach eine Liste mit den für uns relevanten Begriffen plus einer kurzen Erläuterung dazu aufführen.

 

HARDWARE-TREIBER

ALSA (Advanced Linux Sound Architecture): Ein Daten-Treiber, ähnlich wie ASIO, der direkt mit der angeschlossenen Audio-Hardware – hier: USB-Audio-Interfaces/PCI-Soundkarten – kommuniziert und sozusagen die unterste Software-Ebene markiert zwischen Audio-Hardware und Audio-Anwender-Software. Mit der sogenannten DMix-Anwendung, ein virtueller Mixer, lässt sich die Audio-Hardware direkt ansteuern. DAWs und Instrumente, so sie entsprechend ausgelegt sind, können direkt via ALSA auf die Hardware zugreifen und sie ansprechen. Allerdings ist der Austausch zwischen verschiedenen Audio-Anwendungen, etwa DAWs, virtuelle Instrumente, Stand-alone-Effekte wenig erbaulich bis unmöglich. An diese Stelle treten Server- und Dienstprogramme, die sich quasi zwischen ALSA-Schnittstelle und Endanwendung (DAW, Instrumente, etc.) schieben und die ein- und ausgehenden Audio-Datenströme sammeln und verteilen.

FFADO (Free Firewire Audio Drivers): Diese Treiber-Architektur führt das Gleiche wie ALSA aus, nur jetzt ausschließlich für Audio-Hardware, die via Firewire-Schnittstelle mit dem Rechner kommuniziert. Das Vorgänger-Projekt hieß FreeBoB und nicht selten werden beide Versionen einem Atemzug, also FFADO/FreeBoB, genannt.

OSS (Open Sound System): Ein portables Treibersystem für Soundkarten, das auf verschiedenen Unix-Derivaten jenseits von Linux als Quasi-Standard läuft. In Linux war OSS bis zur Kernel-Version 2.4 standardmäßig enthalten, wurde aber mit Veröffentlichung der Linux-Kernel-Version 2.6 von ALSA abgelöst. Per Emulatoren können Programme, die zwingend OSS benötigen weiter betrieben werden.

SOUND-SERVER

PulseAudio: Ein Server-/Dienstprogramm, das sich um die Verteilung von Audio-Strömen nicht nur rechnerintern zwischen verschiedenen Anwendungen, sondern auch zwischen verschiedenen Rechnern in einem Netzwerk kümmert. Es ist – so mein Eindruck – in erster Linie Ansprechpartner für sämtliche Programme jenseits der Audio-Produktion, also Internet-Browser, Audio-/Video-/DVD-Player, Spiele, etc.. Wenn man PulseAudio vergleichen wollte, so würde am ehesten WDM oder DirectX dazu passen. Vorteil: PulseAudio kann Audio simultan aus mehreren Quellen/Programmen/Soundkarten wiedergeben, was entfernt wiederum an die von Propellerhead und Steinberg entwickelte Rewire-Schnittstelle erinnert.

ESD (Enlightened Sound Daemon): Ein Sound-Server der im Zuge der GNOME-Desktop-Umgebung entwickelt wurde und in Verbindung mit dem GStreamer-Framework/Library arbeitet, das sich um das Handling der Codecs kümmert.

aRtsd (Analog Realtime Synthesizer Daemon): Ein Sound-Server, der primär für die K Desktop Umgebung zur Simulation eines Synthesizers entwickelt wurde, aber auch das Verwalten von Audio-Strömen realisiert. Die Weiterentwicklung dieses Servers wurde mittlerweile eingestellt.

Jack (Jack Audio Connection Kit): Ein weiterer Sound-Server, der sich um die Verwaltung der Ein- und Ausgänge von Audio-Programmen und Audio-Hardware kümmert. Im Vergleich zu den übrigen Sound-Servern zeichnet sich Jack durch niedrige Latenzzeiten aus und ist prädestiniert für die Arbeit im virtuellen Tonstudio. Jack nutzt außer ALSA auch FFADO, OSS und PortAudio als Treiber-Schnittstellen zur Hardware. Über das Programm Qjckctl kann der Anwender komfortable Routings zwischen Hard- und Software, Ein- und Ausgängen zwischen verschiedenen Anwendungen und auch das MIDI-Routing unter ALSA realisieren.

 

PLUG-IN-SCHNITTSTELLEN

LADSPA (Linux Audio Developer’s Simple Plugin API): Sozusagen der Urvater der Linux-Plug-in-Schnittstellen. Über LADSPA werden dabei ausschließlich Audio-Signale verarbeitet, weshalb sich ausschließlich Audio-Effekte in diesem Format finden.

DSSI (Disposable Soft Synth Interface): Auf Basis von LADSPA entwickelte Schnittstelle zum Ansteuern virtueller Instrumente und Sampler, wobei MIDI-Daten empfangen und Audio-Signale ausgegeben werden.

LV2: Nachfolger und Weiterentwicklung von LADSPA, der gleichzeitig auch die Funktionalität von DSSI enthält, so dass unter einem Schnittstellenformat sowohl Effekte, als auch Instrumente angesprochen und angesteuert werden können.

VST (Virtual Studio Technology): Vom Hersteller Steinberg entwickelte Plug-in-Schnittstelle, die als Industrie-Standard auf Windows- und Mac-Rechnern etabliert ist. Das VST-SDK (Software Development Kit) besitzt aber durchaus die Fähigkeit, auch auf Linux-Systemen zu laufen. Dafür muss jedoch die Programmierung entsprechend ausfallen, weshalb VST-Plug-ins für Windows oder Mac nicht 1:1 auf Linux-Ebene eingesetzt werden können. In Erweiterung dessen wird daher auch von Linux-VST oder VST for Linux gesprochen, um Plug-ins in diesem Format entsprechend auszuweisen. Eine Reihe von DAWs/Sequenzern ist in der Lage „linuxierte“ VST-Plug-ins einzubinden, etwa der LMMS-Sequenzer oder die Qtractor-DAW. Mit Hilfe von Emulatoren wie Wine ist es zwar möglich, Windows-VST-Plug-ins auch in Linux einzubinden. Doch das geht, so mein Eindruck, (noch?) mit mehr Nachteilen als Vorteilen einher.

 

Fazit: Segen und Fluch der unbegrenzten Treiber- und Schnittstellen-Welt liegen eng beieinander. Das Angebot dieser Möglichkeiten wird in unterschiedlicher Art von den Produzenten von Audio-Software wahrgenommen. So läuft eine DAW wie etwa die des MusiKernel-Projekts (unter Fedora) nur mit PulseAudio, die Ardour-DAW nutzt hingegen Jack. Es gibt daher keinen monopolistischen Standard, sondern eine Standard-Vielfalt, der sich der Anwender, je nach dem, was er einsetzen möchte, stets neu anpassen muss. Dennoch: Bei meinen Recherchen bin ich bislang immer wieder über die gleichen Verdächtigen gestolpert, die sich, so mein Eindruck, für die Audio-Produktion am besten eignen. Dazu zählt ALSA, FFADO, Jack und LV2, nicht zuletzt auch deshalb, weil sie die zurzeit modernsten und aktuellsten Treiber- und Schnittstellen-Architekturen repräsentieren. Daran will ich weiter anknüpfen. Damit möchte ich künftig verstärkt arbeiten.

Im nächsten Teil werde ich deshalb einmal einen näheren Blick auf das oben erwähnte Qjckctl-Programm werfen, das als Frontend zum Verwalten und Routen von Audio-Strömen innerhalb des Jack-Audio-Servers dient.