Ein Jahr später

From JackLab UserWiki

Jump to: navigation, search

Kommentare eines Insiders zu AudioLinux

von Michael Bohle 

This article needs a translation into english A Year Later


Contents

Einführung

Schon vor über einem Jahr hatte ich das viel beachtete „Resümee“(-> de_Resumee ) zu AudioLinux geschrieben. Damals war mir schon klar, was geht und was nicht, und was passieren muss. Nur – zu dem Zeitpunkt war ich noch kein „Insider“ -sondern nur ein begeisterter Musiker, der seine Freude darüber zum Ausdruck bringen wollte, was er gefunden hatte, wie man das anderen zugänglich macht und verbessern könnte. Inzwischen sind viele Kernels kompiliert und einiges hat sich verwirklicht, wenn auch die Wirklichkeit dazu zwingt, Abstriche zu machen. Der folgende Bericht ist sehr subjektiv, zum Teil etwas zynisch, aber spiegelt meine direkten Erfahrungen mit AudioLinux und seinem Umfeld wider. Ich bitte darum, den folgenden Text als Ganzes zu betrachten. Ich will weder jemanden diskreditieren noch hochjubeln, wie der Eindruck enstehen könnte, wenn man einzelne Abschnitte aus dem Zusammenhang reißt. Es geht hier nicht um Für oder Wider und es steckt auch keine abschließende Bewertung dahinter.

Geschichte

Greife ich also ein wenig in der Geschichte zurück und erzähle erstmal chronologisch, was so passiert ist.

Ich hatte Anfang 2005 das Projekt JackLab gegründet, das sich darum kümmert, dass es mit einem SUSE Linux möglich ist, Musik zu produzieren - Pro-Linux berichtete.

In Zusammenarbeit mit freien „Susern" (-> Freiwillige, die RPMs für SUSE Linux erstellen, z.B. PackMan) wurden so die ersten erweiterten Audioprogramme für SUSE Linux per APT4RPM angeboten, die auch von mir und anderen Usern auf Funktion getestet wurden, bevor sie veröffentlicht wurden. Hatte SUSE Linux in der Vergangenheit doch oft zwar solche Programme enthalten, doch wurden diese anscheinend niemals vorher getestet, so dass z.B. der Midi/Audiosequenzer MusE sich nicht starten ließ.

Für ProAudio ist auch ein Audiosystem mit niederiger Latenz nötig, um virtuelle Instrumente mit echtem Gefühl ohne Verzögerung spielen oder nativ berechnete Effekte in Echtzeit benutzen zu können - auf unoptimierten Systemen nur mit ALSA ist die Latenz aber etwa 250ms. Dafür wurde der auf ALSA aufsetzende Audio-Server JACK (JACK Audio Connection Kit) von Paul Davis entwickelt. Doch muss auch der Kernel dies unterstützen, und zwar mit den von Ingo Molnar entwickelten Realtime-Preempt-Patches für die 2.6.x-Kernel. Dieser Patch fügt dem Nicht-Echtzeit-Betriebssystem-Kernel Linux drei mögliche Echtzeitstufen hinzu: Voluntary Kernel Preemption (Desktop), Preemptible Kernel (Low-Latency Desktop) und Complete (Real-Time).

Mit Hilfe eines Kernelhackers wurde ein Tutorial veröffentlicht, wie man sich einen Kernel selber kompiliert, der die erforderliche "Real-Time Preemption" bereitstellt, um seine volle Audio-Performance mit niedriger Latenz bis zu 1 ms ausspielen zu können. Auf Windowssystemen wird die niedrige Latenz einfach mittels Kernelstreaming der Audiotreiber bereitgestellt, ASIO genannt.

Außerdem richtete ich später ein Supportforum für ProAudio-Belange mit SUSE Linux ein.

Es wurde ein CD-Image als eine mögliche Distributionsform angedacht, das aber bisher nur intern getestet und nie veröffentlicht wurde. Als Name für dieses auf openSUSE basierende Multimedia-Linux hat bisher "JackLab Audio Distribution" oder kurz "JAD" Verwendung gefunden.

Inzwischen sind die JackLab-Repositorien wohlgefüllt mit aktueller Audiosoftware für SUSE Linux 10.0 und 10.1, mit einem leicht zu installierenden Audio-Echtzeit JAD-Kernel.

Trägt man „JackLab“ in seinen YAST, Smart- oder APT-Paketmanager ein, so kann man mit Hilfe des im Wiki veröffentlichten Tutorials (-> Nerd 3 Steps to JAD ) leicht sein SUSE zu einer „Digital Audio Workstation“ aufbohren – entsprechende Linuxskills natürlich vorausgesetzt.

Verwandlung openSUSE

In der gleichen Zeit ging auch bei SUSE Linux eine Verwandlung ab, der heutige Besitzer Novell hat ja einige großartige Pläne und krempelte erstmal alles um. Im Oktober 2005 ging opensuse.org in Betrieb, SUSE Linux sollte hier nun eine neue freie Entwicklungsbasis bekommen. Die Perlen der Entwicklung sollten dann in die SUSE-Enterprise-Produkte einfließen. Auch JackLab wurde ein openSUSE Projekt. Ich telefonierte mit verschiedenen SUSE-Mitarbeitern, um aktive und ideelle Hilfe zu bekommen. Ich war ganz begeistert vom Community-Gedanken und der Möglichkeit, dass die Erfahrung der SUSE-Entwickler mit den Bedürfnissen der User in eine SUSE-basierte Musikproduktions-Distribution (JackLab Audio Distribution) einfließen.

Doch die Firmenpolitik des Besitzers Novell machte dem einen Strich durch die Rechnung. Wertvolle SUSE-Mitarbeiter wurden entlassen oder gingen „freiwillig“. Novell braucht SUSE im Kampf um Marktanteile, die Microsoft und Red Hat innehaben. Da ist wenig Platz für ein nur eine Minderheit betreffendes Projekt, das auch noch etwas vertritt was der unbedarfte Außenstehende leicht in eine Spieleecke drängen kann. Um mal mit einem Bild zu sprechen: Das SUSE-Chamäleon wurde von einem amerikanischen Strassenkreuzer überrollt mit dem Kommentar „war nur irgendein Tier“ und soll durch eine amerikanische Fastfood-Superkuh ersetzt werden, die sich in Superlativen äußert. Fast sämtliche früheren Entscheidungsträger bei SUSE sind heute durch amerikanische Manager ersetzt, denen die gewachsene deutsche Benutzerbasis wenig bedeutet. Dabei nimmt die Qualität des Produktes SUSE Linux Schaden und erlebt in Deutschland einen herben Image- und Vertrauensverlust.

Ich werde den Eindruck nicht los, dass die openSUSE-Community heutzutage mehr Alibifunktion hat, um auf Modelle von Überfliegern wie Ubuntu zu reagieren. Doch ist die Zusammenarbeit zwischen Usern und Entwicklern heute schlechter denn je. Bei SUSE regieren heutzutage nur noch Marktanteil und Gewinnprognosen, für Experimente ist wenig bis kein Platz mehr – außer es geht darum, das Produkt „amerikanischer“ zu machen. Und diese Entwicklung erscheint mir sehr „oberflächlich“.

Ubuntu vs. SUSE

Auch andere Linux-Communitys, wie User von Ubuntu, haben das Bedürfnis geäußert, dass mit ihrer Linux-Distribution Musikproduktion möglich wird. Es bildete sich das Projekt ubuntustudio.com, das eine ähnliche Ausrichtung hatte wie JackLab. Es wurde eine Email an Mark Shuttleworth verfasst und darum gebeten, dass solche Überlegungen einfließen, mit dem Ergebnis, dass sich „Dapper Drake“ (Ubuntu 6.06) besser zum Einstieg in das Musikproduzieren mit Linux eignet als zuvor, auch wenn es im Einzelnen noch nicht befriedigt. Außerdem hat die hinter Ubuntu stehende Firma Canonical die Domain „Mubuntu“ registrieren lassen, was darauf schließen lässt, dass ernsthaft an einer solchen Musik/Multimedia-Distribution gearbeitet wird. Ubuntustudio hat mittlerweile seine Ausrichtung von Distributionsprojekt zum reinen User-Support/Dokumentationsprojekt geändert und wartet gespannt auf Mubuntu.

Ubuntu hat eine hohe Userakzeptanz, die nicht zuletzt durch ein intelligentes Marketing verstärkt wird. Es wird hier erfolgreich mit einem „Gutmenschen“-Image gearbeitet, das jedem User das Gefühl gibt, bei einer guten Sache, wie „BandAid“ oder „Greenpeace“ mitzumachen. Die Community wird stark eingebunden in die Entscheidungsprozesse, Menschen unterschiedlichster Couleur arbeiten Seite an Seite für eine freiere, bessere Informations-Welt.

Novell hingegen schafft es, die in Deutschland angestammte Benutzerbasis erfolgreich mit unfertigen und fehlerhaften Distributionen zu vergraulen, doch im internationalen Vergleich steht SUSE nicht schlecht da: Die „Megafeatures“ 3D-Desktop und elegantes GUI-Design werden interessiert aufgenommen, auch ist man im Allgemeinen von dem neuen Novell SUSE Enterprise begeistert. Dass sich qualitativ einige Einschnitte ergeben haben, das bemerkt der amerikanische User gar nicht, weil er erst durch Novell auf SUSE Linux gekommen ist. In Deutschland jedoch werden Stimmen laut, das alte SUSE-Chamäleon wieder in einer freien Variante zum Leben zu erwecken, mit den verlässlichen Qualitätsmerkmalen des guten alten „Nürnberger Windows“.

Hingegen erlebt Ubuntu einen nie gekannten Aufschwung. Schaut man sich ein Ubuntu jedoch mal unter der Haube an, so ist es nicht weit her mit der Benutzerfreundlichkeit – einige Standardkonfigurationstools werden zwar mitgeliefert, doch etwas Vergleichbares wie YAST ist bei Ubuntu noch nicht realisiert. Will man etwas mehr von seinem Linux, so geht es dann nur auf der vom Linuxeinsteiger gefürchteten Konsole und mit Manpages auf Debianart.

Auch ist es noch vergleichsweise schwer, das System zu einem echten low-latency-Audiosystem aufzubohren, da es zum Beispiel noch keinen an Audio-Echtzeit angepaßten Kernel in „universe“ gibt, den muss sich der User selbst kompilieren. Aber durch die Integration des Ubuntustudio innerhalb der Ubuntu-Supportforen findet der mutige User Unterstützung. Die Entscheidungsträger der openSUSE-Community jedoch konnten sich nicht dazu durchringen, ein solches gemeinsames User-Supportportal auch für ihre Produkte anzubieten, so muss JackLab die gesamte Infrastruktur zum Support heute selbst stellen.

AudioLinux-Community

Im April bin ich mit meinen Audio-Computern dann zur jährlich stattfindenden Linux Audio Conference gefahren, um die Vor-Form der „JackLab Audio Distribution“ den Audio-Entwicklern und Anwendern als solide, performante und benutzerfreundliche Basis vorzustellen. Leider hat nämlich SUSE Linux bei den Entwicklern einen schlechten Ruf, der daraus resultiert, dass man Kompromisse für die Benutzerfreundlichkeit eingegangen war. Entwickler und Geeks lassen sich jedoch ungern von Tools wie YaST bevormunden und bevorzugen deshalb eher Gentoo oder Debian, die allerdings für den gewillten Einsteiger nur mit sehr viel Aufwand und Lernbereitschaft zu handhaben sind. Ich meine aber, dass Musikmachen und Produzieren schon aufwendig genug ist und man dabei nicht noch zum Linux-Nerd werden muss. Auf der LAC habe ich sie dann alle mal getroffen und mit vielen von ihnen später in der „Linux Sound Night“ gejammt. Ich muss sagen, ich habe mich wie zuhause gefühlt und die Begegnung verlief sehr positiv, wenn auch anscheinend folgenlos.

Mir ist nun völlig klar, wer die Menschen hinter AudioLinux sind und warum einiges so ist, wie es ist. Es sind in erster Linie "ganz normale Leute" mit Musik- und Computer-Affinität, die in ihrer Freizeit oder im akademischen Rahmen sich auf ihrer Lieblingsbasis Linux darum kümmern, dass es auch Töne macht. Hierbei geht es nicht in erster Linie um die Erwartungen von Pop-Produzenten und Musikkonsumenten, sondern darum, elektronisch-experimentelle Klangwelten zu verwirklichen, die weit vom Mainstream in Nischen stattfinden. Benutzerfreundlichkeit und Hype-Features spielen hierbei nur eine untergeordnete Rolle. Wenn es etwas zu verbessern gibt, dann wird es irgendwann getan, aber es ist nur ein Hobby und hat keine Eile, man kann gut mit Workarounds leben.

Mit wenigen Ausnahmen, die von einem kommerziellen Background ausgehen, wie z.B. Ardour oder Rosegarden, sind die Linux-Audioprogramme oft mehr ein „proof of concept“ als stabile, erwachsene Produktionstools. Die Modularität mit mangelnder „Total recall“ Unterstützung - also der Fähigkeit, alle am Arrangment beteiligten Musikprogramme gemeinsam zu speichern, wird zwar problematisiert, doch dessen Lösung, ein Sessionmangement namens LASH wird nur sehr unmotiviert eingebunden, da man ja primär kein Bedürfnis hat bzw. keine Zeit.

Außerdem gibt es wenig verbindliche Richtlinien: Man ist sich einig, dass JACK wichtig ist und bei LADSPA-PlugIns (Linux Audio Developer Simple Plugin API, Effektgeräte für AudioHosts wie Ardour, Hydrogen usw.) kommt man sich auch noch einigermaßen entgegen. Aber schon bei Instrumentplugins ist man sich nicht einig: So hat MusE zur Zeit ein anders Instrument-Pluginformat als „Rosegarden“, die natürlich völlig inkompatibel zueinander sind. Allerdings hat mir der Entwickler von MusE, Werner Schweer, auf der LAC verraten, dass die DSSI-Einbindung kommt.

Das Thema VST ist problematisch. Virtual Studio Technologie ist von der deutschen Softwareschmiede Steinberg entwickelter Quasi-Standard für virtuelle Instrumente und Effekte, die in einem Host-Sequenzer Verwendung finden. Die Mehrheit der Linux-Audioentwickler lehnt diese extrem populäre, aber proprietäre Schnittstelle ab, zumal ein Betrieb von VST auf Linux bisher auch noch WINE erfordert. Dies wird durch VST-Wrapper erledigt, die dann die Windows-Laufzeitbiblothek (DLL) laden und übersetzen. Oft spielen ideologische Gründe eine Rolle für eine Ablehnung, die für Anwender schwer nachzuvollziehen sind. Außerdem gibt es noch die Lizenzfallen durch die restriktive GPL, die es nicht zulässt, proprietären und freien Code zu vermischen - oder wenn man es andersrum ausdrückt – man sehe es gern, dass Steinberg das VST-Format zu Open Source erklärt (was total unrealistisch ist), und vertröstet den User auf die existierenden LADSPA-Effekt-Plugins und auf die sechs DSSI-Plugins. Oder der Anwender soll die Hostsoftware selber mit einer VST-Option kompilieren - wie bei Ardour (Recording/DAW), FST (VST Wrapper), LMMS (Fruity Loops nachempfunden).

Kurz und gut – bei den meisten Linux-Audio-Entwicklern besteht anscheinend gar kein großes Interesse, dass sich Linux bei Musikern stark verbreitet. Man könnte zum Teil fast meinen, sie bewachen eifersüchtig ihre kleine Spielwiese und achten darauf, dass die böse Welt des Mainstreams und der Superstars sich erst gar nicht wohlfühlt.

Andere, die heutzutage schon versuchen, kommerziell zu vermarkten, was Audiolinux zu bieten hat, treten auf der Stelle. So ist Ardour bis heute nicht in der Lage, eine vollständige Produktionsumgebung zu bieten, weil ein Midisequenzer immer noch nicht eingebunden ist. Der von Google initierte „Summer of Code“ sponsort diese Entwicklung nun und ich hoffe, dass man mit Ardour 2007 so langsam die Features aufweisen kann, die Cubase schon 1998 bot. Die Entwicklung findet im Zeitlupentempo statt. Für den normalen User hat sich seit letztem Jahr nur wenig getan auf AudioLinux.

Gebet erhört?

Letztes Jahr schrieb ich auch, dass ich denke, wenn es für Linux einen kommerziellen Sequenzer nach Art eines Cubase oder Logic gebe, für den normalen User der Einstieg besser möglich wäre. Ich hatte den Programmierer der inzwischen von Mackie vertriebenen Studiosoftware Tracktion gefragt ob er seinen Sequenzer nicht für Linux portieren mag, zumal er mit JUCE eine Cross-Plattform-Bibliothek freigegeben hatte, doch der hielt die Linux-Audio-Schnittstellen für zu schlecht dokumentiert. Auch andere Audio-Entwickler aus der Mac/Windows-Ecke sind der Meinung, dass der gesamte Unterbau zu „trashig“ sei, als dass man da was aufbauen könne.

Was sich allerdings auf der Windowsplattform in den letzten Jahren getan hat, grenzt an ein Wunder. Längst haben kleinere VST-basierte Studiolösungen wie energyXT oder Reaper (der auch per Wine auf Linux läuft) solchen Boliden wie Cubase den Monopolrang abgelaufen. Es ist erstaunlich, mit welcher Geschwindigkeit solche (zum Teil Ein-Mann-Unternehmen) sich entwickeln und welche Features sie heute bieten. Dabei kosten diese Lösungen oft nur ein Bruchteil einer etablierten Lösung und sind einfach durch hunderte zum Teil frei erhältlicher VST-PlugIns erweiterbar.

Da stellt sich die Frage, wenn es für wenig Geld und Wissen leicht möglich ist, ein sowieso zum Computer geliefertes Windows in eine professionelle Studioumgebung zu verwandeln, warum sollte sich der geneigte Anwender überhaupt ein Linux anschauen, das kaum mehr als ein paar verstreute Klangerzeuger und halbfertige Sequenzer bietet, das frickelig zu bedienen ist und auch noch kompliziert?

Das Feedback der potentiellen User (also Musiker, die rauswollen aus der Windows/Crack/Viren Ecke) sagt da einiges: Zwar ist das Interesse hoch, doch wagt es jemand mal tatsächlich, sich ein Linux als Parallelsystem zu Windows zu installieren, folgt die Ernüchterung schnell. Sicher, Linux ist hervorragend für den Büroanwender und auch der kreative Pixelkünstler dürfte einige gute Anwendungen finden. Aber ob sich der Aufwand lohnt, die technischen Einschränkungen eines Audio-optimierten Systems in Kauf zu nehmen? Jedenfalls zeigt meine Beobachtung, dass nur sehr wenige bei Linux bleiben. Ich selber habe alles versucht, kreativ produktiv mit Linux zu arbeiten. Doch außer ein paar unfertigen Skizzen habe ich auf Linux innerhalb eines Jahres nichts Kreatives fertigstellen können.

Was gut funktioniert ist spontanes, Prozeß-orientiertes experimentelles Jammen. Zielorientierte Anwendungen, die auch gut funktionieren, sind Recording und Postproduktion. Jedoch stellte sich für mich das zielorientierte kreative Komponieren und Produzieren im virtuellen Studio als schwierig heraus. Die mangelnde „Total Recall“ Fähigkeit der modularen Applikationen entpuppte sich als Hemmschuh, der verhinderte, dass ich überhaupt Lust hatte, etwas auszuarbeiten, bedeutet dies doch immer auch, jede Instanz eines Sounderzeugers nach Ardour zu routen um es dort aufzunehmen und anschließend die ganzen beteiligten Hilfssequenzer und Klangerzeuger einzeln abzuspeichern. Das Sessionmangement LASH hat sich in seiner jetzigen Form als nicht praxistauglich erwiesen. Ein normales Arrangement umfasst aber bei mir etwa 15 Programme, die beteiligt sind. Damit habe ich eine sparsame Version dessen, was ich unter anderen Plattformen als kleines Arrangement bezeichnen würde – jedoch auf Linux ein Berg, der mir im vornherein schon die Lust genommen hat. Und wenn man sich dann auch noch auf die wenigen wirklich stabilen Programme beschränkt, bleibt nicht mehr viel – im Vergleich zu einer billigen Studiolösung auf Windows. Auch Mac OS X bietet mit dem beigelegten Garageband ein nettes Werkzeug für den kreativen Heimanwender ohne Aufpreis.

Also entschied ich mich dafür, Recording und Postproduktion mit Ardour und Linux in meinem Studio und live auf einem eigens dafür angefertigten Referenzrechner zu betreiben, aber sämtliche virtuell-kreative Produktion auf Windows mit dem modularen Audio/Midisequenzer energyXT des norwegischen Programmierers Jorgen Aase zu realisieren. Der ist als Shareware erhältlich für 39€ und bietet den Rahmen, um ihn zu einer Art Cubase mit völlig freiem Routing zu erweitern. Mit ein Grund für diese Entscheidung ist, dass Jorgen Aase eine native Linux-Version des Nachfolgers energyXT2 angekündigt hat.

Erwartungen an energyXT2

Mit der Windowsversion eXT 1.3 habe ich das Recht auf ein Update/Cross Update auf eXT2 erworben. Jorgen Aase ist auch im permanenten Kontakt mit seiner User-Community und nimmt „Feature Requests“ an. Innerhalb dessen, was ihm möglich ist baut er dann auch diese Features ein. Als ich erfuhr, dass er eXT2 für Linux nur mit der obsoleten OSS-Audioschnittstelle ausliefern will, aber ansonsten die Schnittstelle offen lässt, war ich zunächst etwas enttäuscht. Meines Erachtens hat eine professionelle Applikation nur mit JACK-Unterstützung eine ernsthafte Chance auf Linux. Jorgen bestritt zunächst, dass JACK wichtig sei, da eXT2 alpha jetzt schon nativ eine niedrige interne Latenz mitbringt. Auf die Features von JACK, die Synchronisierbarkeit und das Ineinanderrouten der Applikationen, ging er gar nicht ein. Später jedoch, nachdem ich deutlich intervenierte, schaute er sich das JACK-API einmal an und merkte an, dass dies leicht einzubinden sei.

Ein anderes Feature in der Windowsversion ist die Einbindung von VST-Instrumenten und -Effekten. Erst dadurch wird eXT groß und universal benutzbar. Da es aber mangels des geschäftlichen Interesses von Steinberg keine native Linux-VST-Schnittstelle gibt, fragte ich mich, wie Jorgen Aase das lösen will. Er kündigte daraufhin an, dass er nun VST-Plugins auf Linux nativ kompilieren will. Das ist eine absolute Sensation, noch nie zuvor hat ein Einzelner es gewagt, einen so wichtigen und entscheidenden Schritt zu tun – denn damit würde sich die VST-Schnittstelle unabhängig von Schöpfer der selben, nämlich Steinberg, auf Linux etablieren.

Die Erwartungen sind von meiner Seite hoch – wenn Jorgen Aase es schafft, dann wird auch Audio-Linux beim kreativen Anwender ankommen. Das würde der Durchbruch werden. Ich denke, auch viele Freeware-Autoren werden gerne eine Linux-Version ihrer VST-Plugins anbieten. Es wird eine kleine Revolution, die vieles an Kritikpunkten beseitigt und den großen Konzernen wie Apple und Yamaha, die heutzutage das Musikproduktions-Softwaregeschäft dominieren, ein Dorn im Auge sein wird. Man wird Preise und Firmenpolitik und die Haltung zu Open Source überdenken. Aber Revolutionen kommen immer von unten und werden von der herrschenden Klasse solange ignoriert, bis ihr das Wasser bis zum Hals steht.

Klar, Jorgen Aase ist kein Open-Source Programmierer, aber er hatte einst den Mut, zu sagen, dass er von seiner Arbeit leben und sie gut machen will. Seine Entscheidung, eXT2 für Linux zu machen, kam daher, dass er im Alltag Ubuntu schätzt und Linux gerne anwendet.

Wenn eXT2 herauskommt, wird es stabil sein und man kann damit arbeiten - sofort. Was Ardour, Rosegarden und MusE seit Jahren versprechen, wird eXT2 halten. Jorgen Aase ist nämlich unabhängig von der „alles umsonst, Open Source“-Ideologie und gibt zu, dass er von den 39€ pro Lizenz gut leben kann und dieses Jahr sogar schon im Urlaub in Italien war, und das, obwohl es eine gecrackte Version des Programms in den einschlägigen Tauschbörsen gibt.

Maßnahmen

Viele fragen sich heute, wo den das angekündigte CD/DVD-Image der „JackLab Audio Distribution“ bleibt. Es soll ein reduziertes, angepasstes SUSE-Basissystem enthalten, angereichert mit einem RT-Kernel, Audio-Applikationen und einer Mischung aus Enlightenment17 und KDE als User-Interface.

Prinzipell ist sowas auch technisch relativ leicht zu verwirklichen. Vereinfacht ausgedrückt: Man passt nur ein paar SUSE-Steuerdateien des Installations-YAST an, tauscht den Kernel aus, fügt ein paar RPMs hinzu, liest diese ein und gibt dann den passenden mkisofs-Befehl ein, um das Image zu bauen. Das Projekt SUPER von opensuse.org (das allerdings anscheinend nicht mehr gepflegt wird) gibt da schon einiges an Wissen vor. Doch steckt der Teufel im Detail und außerdem ist der SUSE-Build-Prozess sehr schlecht dokumentiert und die letzten verbliebenen SUSE-Hohepriester haben zumeist das Interesse und die Zeit verloren, in ihrer Freizeit kleinen „Underdog“-Projekten die nötige Unterstützung zu erteilen.

Einerseits erwartet man von uns, es ganz alleine auf die Reihe zu kriegen; doch selbst ehemalige SUSE-Mitarbeiter haben heute Schwierigkeiten, gezielt an hilfreiche Dokumentation zu kommen. Hinzu kommt, dass JackLab nur sehr wenige aktive Mitarbeiter hat, von einem Team kann man kaum mehr sprechen. Dabei müssen die wenigen, die sich um technische Belange kümmern, sich jeden Schritt mühsam selber beibringen.

Inwieweit wir den SUSE Build Service nutzen können, um die JackLab-Audio-Distribution zu bauen oder RPMs zu verwalten, ist noch nicht klar. Zum einen ist dieser Service noch sehr Beta und deshalb zum Teil relativ unzuverlässig. Außerdem mangelt es an Dokumentation. Das größte Problem jedoch werden die von Novell auferlegten Beschränkungen auf "offene Software" sein, denn viele Audio-Programme, die unter der GPL lizenziert werden, benutzen doch zum Kompilieren proprietäre Bibliotheken. Vieles, was der Media-Anwender auf Mac oder Windows als selbstverständlich erachtet, ist unter Linux ein großes Problem, denn paradoxerweise schließt die Offenheit vieles aus.

Glücklicherweise haben wir inzwischen jedoch eine Zusammenarbeit mit dem ehemaligen „SUSE Press“ vereinbart, das heute als unabhängiger Ein-Mann Betrieb Millin-Verlag von Nicolaus Millin sehr engagiert geführt wird. Seine neueste Produktlinie „vorkon“ mit angepassten Versionen der offenen SUSE wird gut vom Anwender angenommen und unser Projekt passt da gut ins Konzept.

Meine Idee ist es, dass wir eine „vorkon“-Version mit Audio-Applikationen und RT-Kernel bringen, den Kaufanreiz aber dadurch steigern, dass man einige verbilligte Lizenzen von professionellen Audioprogrammen sowie Sample-Bibliotheken anbietet. Ich habe Nicolaus Millin aber klargemacht, dass noch einiges zu tun ist, bevor sowas vermarktungsfähig ist. Er ist aber bereit, sich an dieser Entwicklung zu beteiligen, somit ist dann wohl ein wirklich fähiger ehemaliger SUSE-Mitarbeiter mit JackLab assoziiert, der auch durch marktorientiertes Denken die Entwicklung beschleunigt.

Natürlich werden wir weiterhin das JackLab-Repositorium frei und gratis zur Verfügung stellen – ich möchte jetzt schon Interessierte einladen, sich an den Beta-Tests zu beteiligen, die in Kürze für eine „vorkon“ Musik/Multimedia-OpenSUSE beginnen. Außerdem werden eine öffentliche Mailingliste sowie das Userportal „jacklab.org“ eingerichtet.

Abschluss

Da ich diesen Artikel vor der Veröffentlichung auf pro-linux.de noch mit z.B. dem deutschen Forum von audio4linux.de diskutiert habe, möchte ich abschließend noch ein paar Anmerkungen anbringen.

Natürlich gibt die bisherige Arbeit der Entwickler an AudioLinux eine wunderbare Basis für Musikproduktion unter Linux, auch wenn noch nicht alles optimal ist. Es ist aber auch an den Distributoren, einen "Realtime Full Preemtion" Kernel optional für Musikproduzierende anzubieten.

Das Problem ist häufig, dass bestimmte Funktionen und Treiber "zerbrechen", wenn dieser RT-Patch angewendet wird. Unser JackLab-Kernelhacker hat Wochen gebraucht, um den SUSE-Standard-Kernel für 10.0 in der Form zu packen, dass er den SUSE-Konventionen entspricht und sich einigermaßen ins System einfügt. Mit SUSE Linux 10.1 hat sich jedoch schon wieder so vieles im System geändert, das aber nicht dokumentiert wurde, dass wir uns dazu entschieden haben, die SUSE-Patches zugunsten der Audio-Echtzeit wegzulassen.

Letztlich werden die RT-Patches von Ingo Molnar eines Tages im Kernel Einzug halten, da Desktop-Multimedia-Anwendungen immer wichtiger werden. Einst war SUSE bekannt für seine Vorreiterrolle im Audiobereich, und mit Hilfe von auf der Gehaltsliste von Novell stehenden ALSA-Entwicklern wäre es ein Leichtes, an diesen Ruf wieder anzuknüpfen.

Aber während Novell noch kurzsichtig auf Gewinnprognosen schielt und unprofitabele Bereiche absägt, ist Canonical mit (M)Ubuntu schon einen Schritt weiter, hört der Community zu, erkennt diese Anwendergruppe an und wird trotzdem mehr Umsatz machen.

Auch möchte ich geniale Entwicklungen wie Netjack kurz erwähnen, mit dem es möglich ist, einen Echtzeit-Cluster von Musikrechnern zu realisieren, ohne dass das Clientsystem über eine eigene Audiohardware verfügt. Gäbe es mehr professionell designte Audio/Multimedia-Anwendungen, die es wagen, sich auf die Probleme einzulassen und die Chancen zu nutzen, könnte Linux gerade im High-End-ProAudio-Bereich punkten. Im Embedded-Bereich werden jetzt schon erfolgreich Linux-Lösungen angewendet, siehe Korg Oasys oder Muse Receptor.

Aber auch andere Betriebssysteme bieten ihren Anwendern auf einfache Weise die Möglichkeit, Musik/Multimedia zu produzieren. Soll Linux wirklich beim Anwender ankommen, so gehört das einfach dazu wie ein Schreibprogramm und ist keine unwichtige Spielerei. Selber zu produzieren ist heute auch ein ganz normales, kommunikatives Anwendungsgebiet, seien es Videoblogs oder Podcasts. Nicht nur Musiker haben etwas von einem Musiker-Linux - die Konsumenten werden profitieren, da mehr freie, aber professionell produzierte Musik erhältlich sein wird.

Retrieved from "http://wiki.jacklab.net/index.php/Ein_Jahr_sp%C3%A4ter"
Personal tools