Bild von Gigxels .com auf Pixabay
Ich erinnere mich genau an den Moment, in dem Linux-Audio für mich kippte. Es war irgendwann um 2008, ich hatte gerade Ubuntu 8.04 Hardy Heron installiert, und ich wollte einfach nur YouTube schauen, während im Hintergrund Musik lief. Stattdessen passierte das, was zu der Zeit jeder kannte: Der Browser war stumm, der Musikplayer auch, und in einem Terminal blinkte ein Cursor, der mich auslachte. Ich löschte ~/.pulse, startete neu, fluchte, las ein Forum, kopierte einen Befehl, von dem ich nicht verstand, was er tat und am nächsten Morgen war alles wieder anders kaputt.
Wenn du Linux vor 2014 ernsthaft genutzt hast, kennst du diese Szene. Vielleicht war es bei dir Skype, das die Soundkarte exklusiv blockierte. Vielleicht Flash, das mit jeder zweiten Aktualisierung den Ton frass. Vielleicht war es schlicht das Bluetooth-Headset, das in mono klang, wenn ein Mikrofon aktiv war. Linux-Audio war jahrelang ein Witz, und das Schlimme war: Es war ein Insider-Witz, über den niemand wirklich lachen konnte.
Heute, im Jahr 2026, ist das Thema durch. Mein Bluetooth-Kopfhörer verbindet sich beim ersten Versuch in CD-Qualität. Mein Mikrofon läuft durch eine systemweite Filterkette mit Noise-Suppression, Equalizer und Kompressor, ohne dass ich auch nur ein Konfigurationsfile angefasst habe. Und wenn ich Lust hätte, könnte ich mit einer Latenz von unter zwei Millisekunden Gitarre aufnehmen, was auf einem Mac der gleichen Preisklasse so direkt nicht geht. Linux hat heute den mächtigsten und flexibelsten Audio-Stack aller Desktop-Betriebssysteme. Das ist keine Fanboy-Behauptung, sondern das Resultat von dreissig Jahren Schmerz, Streit und drei sehr unterschiedlichen Männern.
Dieser erste Teil erzählt, wie es dazu kam.
Akt 1: Der finnische Pionier und sein Sündenfall (1992)
Die Geschichte beginnt 1992 mit einem finnischen Studenten namens Hannu Savolainen. Er hatte angefangen, einen Sound-Blaster-Treiber für Minix zu schreiben, das Projekt aber wieder aufgegeben. Stattdessen portierte er den Treiber auf dieses neue Linux, das damals gerade ein Jahr alt war.
Was als Wochenend-Hack begann, wurde unter dem Namen Open Sound System (OSS) zum Standard für Linux-Audio - und nicht nur für Linux. Auf vielen Unix-Derivaten setzte sich OSS ebenfalls als Quasi-Standard durch.
Savolainen wurde von der Firma "4Front Technologies" unter Vertrag genommen, und gemeinsam beschlossen sie, mit OSS Geld zu verdienen. Er stellte die Arbeit an der freien GPL-Version praktisch ein und entwickelte fortan das proprietäre OSS für 4Front. Die freie Version im Linux-Kernel blieb auf Version 3.8 stehen. Das war der Moment, in dem Linux-Audio den ersten echten Knacks bekam, nicht durch Inkompetenz, sondern durch eine Lizenz-Entscheidung.
Die Community improvisierte. Red Hat sponserte den legendären Linux-Entwickler Alan Cox dafür, die Kernel-Soundtreiber zu modularisieren und Bugs zu beheben. Die Ergebnisse landeten zuerst in Red Hat 5.0 und später im Mainline-Kernel. Aber als Red Hat das Sponsoring einstellte, fehlte ein dedizierter Maintainer und OSS in seiner freien Form trat in eine lange Stagnationsphase ein.
Erst am 14. Juni 2007 stellte 4Front OSS schliesslich unter freie Lizenzen. Da war der Zug abgefahren. Ein Kommentator nannte es damals treffend "too little, too late". Die Versöhnung kam fünfzehn Jahre zu spät, und der Schaden war längst angerichtet. Aber das eigentliche Problem von OSS war nicht die Lizenz. Das eigentliche Problem war das technisch Fundament.
Bei OSS konnte nur ein Programm gleichzeitig die Soundkarte benutzen.
Das ist heute schwer vorstellbar. Aber stell dir vor: Du startest deinen Musikplayer. Dann öffnet sich ein Chat-Fenster und will einen Benachrichtigungston spielen. Antwort: kein Ton. Du startest ein Spiel: Musikplayer schweigt. Du öffnest einen Browser mit einem Video: irgendetwas davon bekommt Sound, was anderes nicht. Was Windows und Mac OS schon Mitte der Neunziger gelöst hatten, war auf Linux jahrelang unmöglich.
Akt 2: Der Zoo (1998 bis 2007)
Die Antwort auf das Mixing-Problem kam aus zwei Richtungen gleichzeitig und das wurde zu einem eigenständigen Problem.
Auf der Kernel-Seite übernahm ein tschechischer Systemadministrator namens Jaroslav Kysela. Er wollte aus seiner Gravis-UltraSound-Karte mehr herausholen, als die existierende API bot, und begann mit der Arbeit an einem neuen Sound-System: der Advanced Linux Sound Architecture, kurz ALSA. Die erste Veröffentlichung kam 1998. Mit dem 2.6er-Kernel wurde ALSA der offizielle Standard, und OSS wurde als veraltet markiert. ALSA ist bis heute die Kernel-Schicht, über die letztlich alles läuft. Wenn dein Linux heute ein Geräusch ausgibt, ist ALSA dabei egal, was sonst noch im Spiel ist.
Aber ALSA allein war nicht genug. Software-Mixing war zwar über das dmix-Plugin möglich, aber kompliziert zu konfigurieren. Und wenn du jemals eine .asoundrc von Hand editiert hast, weisst du, was ich meine. Also entstanden im Userspace zwei völlig unterschiedliche Soundserver, die beide ALSA als Unterbau nutzten und die sich gegenseitig im Weg standen.
Auf der GNOME-Seite gab es den Enlightened Sound Daemon, kurz ESD oder EsounD. Ursprünglich für den Window Manager Enlightenment geschrieben, wurde er zum Standard in vielen Distributionen. Er konnte mehrere Audio-Streams mischen und hatte sogar Netzwerk-Transparenz, du konntest theoretisch Musik vom einen Rechner auf den Lautsprechern eines anderen abspielen. Klingt cool, brauchte aber niemand. Seit dem Jahr 2000 wurde EsounD nicht mehr aktiv weiterentwickelt, aber er blieb der Default in GNOME, weil sich niemand traute, ihn anzufassen.
Auf der KDE-Seite gab es aRts, den Analog Real-time Synthesizer von Stefan Westerfeld. Er war ambitionierter als ESD, konnte mehr, hatte besseren Sound, und kostete dafür mehr CPU. 2004 verkündete Westerfeld, dass er das Projekt aus einer Reihe fundamentaler Gründe verlasse: aRts war tot, KDE musste sich nach einer neuen Lösung umsehen.
Daneben gab es noch das Network Audio System für Thin Clients, GStreamer als Multimedia-Framework, und natürlich JACK aber zu JACK kommen wir gleich. Das Resultat dieses Zoos war, dass es für App-Entwickler keine klare Antwort darauf gab, welches Audio-API sie verwenden sollten. Manche schrieben für ALSA direkt. Andere für ESD. Andere für aRts. Manche, wie Audacity, wählten PortAudio für Cross-Plattform-Kompatibilität. Und einzelne machten alles intern.
Wenn du dich heute fragst, warum Linux-Audio früher so frustrierend war, das war der Grund. Nicht weil eine einzige Sache kaputt war. Sondern weil sechs Sachen parallel existierten, alle halb funktionierten und keine miteinander redete.
Zwischenakt: Die Profis machen ihr eigenes Ding (2002)
Während der Consumer-Zoo wuchs, passierte parallel etwas völlig anderes. Paul Davis, ein britisch-amerikanischer Entwickler mit ungewöhnlicher Vita, er war einer der ersten beiden Programmierer bei Amazon. Bevor er sich der Audio-Software zuwandte, arbeitete an einer Digital Audio Workstation namens Ardour. Aus dem Audio-Code, den er dafür geschrieben hatte, entstand 2002 das JACK Audio Connection Kit.
JACK war der Anti-PulseAudio, bevor PulseAudio existierte. Wo der Consumer-Zoo versuchte, Audio für den Durchschnittsanwender hinzubekommen, hatte JACK ein einziges Ziel: maximale Präzision für Profis. Jede Anwendung war ein Knoten in einem Graphen, alle Knoten wurden sample-genau synchronisiert, und die Latenzen lagen bei wenigen Millisekunden. Davis erhielt 2004 dafür einen Open Source Award.
Was viele nicht wissen: JACK hat den Linux-Kernel selbst verändert. Die Anforderungen an niedrige Latenzen waren einer der Antriebe für die Realtime-Optimierungen der 2.6er-Kernel-Serie und führten letztlich zum CONFIG_PREEMPT_RT-Patch. Wer heute auf Linux mit niedriger Latenz arbeiten kann - sei es für Musikproduktion oder Gaming - profitiert von Arbeit, die ursprünglich für JACK gemacht wurde.
Das Problem war: JACK war für Konsumenten unbrauchbar. Du musstest ihn manuell starten, deine Audio-Hardware genau kennen, und die meisten Apps konnten ohnehin nicht mit ihm reden. Pro-Audio auf der einen Seite, Consumer-Chaos auf der anderen, und keine Brücke dazwischen.
Akt 3: Der Disruptor aus Hamburg
In dieses Chaos hinein kommt eine der streitbarsten Figuren der Linux-Welt: Lennart Poettering. Geboren 1980 in Guatemala-Stadt, aufgewachsen in Rio de Janeiro und Hamburg, Informatik-Student. 2004 begann er mit einem Projekt, das ursprünglich Polypaudio hiess. Version 0.7 erschien am 22. November später wurde es in PulseAudio umbenannt.
Poetterings Ansatz war: Wir ersetzen ESD und aRts und alles andere durch einen einzigen, modernen Soundserver, der gleichzeitig Mixing, Per-Application-Volume, Glitch-free-Audio und Network-Audio kann. Auf dem Papier war das genau das, was Linux brauchte. In der Praxis wurde es zur grössten Audio-Katastrophe, die das Linux-Ecosystem je erlebt hatte.
2007 wurde PulseAudio Default in Fedora 8. Im April 2008 zog Ubuntu mit Hardy Heron 8.04 nach. Und genau da explodierte alles. Ubuntu 8.04 wurde berüchtigt für kaputtes Audio. Foren liefen über, Bug-Tracker quollen über, Matt Cutts schrieb seinen berühmt-berüchtigten Blogpost über die Six Annoyances in Hardy Heron Ubuntu, in dem PulseAudio prominent vorkam. Skype crashte, Flash crashte, Adobe schob die Schuld auf Linux, Linux schob sie auf Adobe.
Auf der Linux Plumbers Conference im September 2008 hielt Poettering einen Vortrag, der heute legendär ist. Sein Aufmacher für den Zustand von Linux-Audio: "it's a mess". Und über sein eigenes Projekt sagte er, es sei für aktuelle Nutzer "the software that currently breaks your audio". Das ist - und das musst du anerkennen - eine sehr ehrliche Selbsteinschätzung. Später erklärte er, Ubuntu habe seine Hausaufgaben bei der Adoption nicht gemacht. Was technisch nicht falsch war, aber den frustrierten Endnutzer wenig tröstete, wenn sein Headset stumm blieb.
Die Kritik an PulseAudio war damals teils unfair, teils brutal verdient. PulseAudio war 2004 für die damals übliche Hardware extrem CPU-hungrig. Es hatte die unangenehme Eigenschaft, sich ohne ersichtlichen Grund auf 100 Prozent CPU hochzudrehen. SPDIF-Passthrough funktionierte erst korrekt, als SPDIF schon durch HDMI abgelöst war. Die ehrliche Bilanz aus der Community: PulseAudio wurde 2004 veröffentlicht und war erst um 2012 bis 2014 herum wirklich brauchbar.
Und doch hat PulseAudio einen entscheidenden Beitrag geleistet, ohne den die heutige Linux-Audio-Welt nicht existieren würde. Per-Application Volume Control. Die Tatsache, dass du Firefox leiser stellen kannst als deinen Musikplayer, dass jede Anwendung ihren eigenen Lautstärke-Slider hat, dass du Audio von einem Gerät auf ein anderes umleiten kannst, ohne irgendetwas neu zu starten all das haben wir Lennart Poettering zu verdanken. Es war die erste echte Konsumenten-Innovation im Linux-Audio seit über einem Jahrzehnt.
Poettering ging 2010 dann zum nächsten kontroversen Projekt: systemd. Und 2022 verliess er Red Hat in Richtung Microsoft.
Akt 4: Der Belgier löst das Problem
Es brauchte einen Mann, der vom Streit müde genug war, um ihn schweigend zu beenden. Sein Name ist Wim Taymans, geboren 1972 in Belgien, einer der Co-Schöpfer von GStreamer und seit Jahren Principal Engineer bei Red Hat. Im Juli 2015 kündigte er ein neues Projekt an, das ursprünglich nicht einmal mit Audio sondern mit Video zu tun hatte.
Das Projekt hiess zunächst Pinos, nach dem spanischen Ort Pinos de Alhaurin, in dem Taymans damals lebte. Es basierte auf Ideen aus einem älteren Prototyp namens PulseVideo von William Manley und sollte für Video das tun, was PulseAudio für Audio gemacht hatte: ein einheitlicher, sicherer Server, der mehreren Anwendungen den Zugriff auf Kameras und Video-Streams ermöglicht. Insbesondere für das damals neue Wayland und für Sandbox-Anwendungen wie Snaps und Flatpak war das dringend nötig.
Anfang 2017 begann Taymans, Audio in Pinos zu integrieren. Er stellte fest, dass die Architektur, die er für Video entworfen hatte, mit ein paar Anpassungen auch Audio mit niedriger Latenz handhaben konnte. In seinen eigenen Worten aus seinem GStreamer-Conference-Vortrag von 2017: "It looked like JACK but without low-latency guarantees." Also baute er die Latenz-Garantien ein, benannte das Ganze in PipeWire um, und erweiterte den Anspruch dramatisch: ein einziger Server für Audio und Video, der gleichzeitig die APIs von PulseAudio, JACK und ALSA emulieren kann.
Das war der Geniestreich. Niemand musste etwas umschreiben. Bestehende PulseAudio-Apps funktionierten weiter, weil PipeWire so tat, als wäre es PulseAudio. JACK-Apps funktionierten weiter, weil PipeWire so tat, als wäre es JACK. Und gleichzeitig konnte PipeWire das, was beide Vorgänger nie konnten: Audio und Video aus einem Container-Sandbox heraus sicher handhaben.
Die Adoption ging dann auffällig schnell und leise. Fedora 27 brachte 2017 die ersten Video-Funktionen. Fedora 34 wurde im April 2021 die erste grosse Distro mit PipeWire als Default-Audio-Server. Die meisten Nutzer haben es schlicht nicht bemerkt, weil ihre Anwendungen einfach weiter funktionierten. Ubuntu 22.10 zog im Oktober 2022 nach, Debian 12 im Jahr 2023. Am 26. November 2023, nach mehr als vierzig Entwicklungs-Releases, erschien PipeWire 1.0. Stabil, ausgereift, der neue Standard.
Bei PulseAudio war die Adoption ein Drama, das Jahre brauchte, um sich zu beruhigen. Bei PipeWire war die Adoption so unauffällig, dass die meisten erst aus Fachartikeln erfuhren, dass sie es überhaupt benutzten.
Was wir daraus lernen
Drei Generationen, drei Persönlichkeiten, drei Lösungsansätze. Hannu Savolainen war der Pionier, der den freien Geist hinter sich liess und damit die Stagnation einleitete. Lennart Poettering war der Disruptor, der mit Brachialgewalt den Status quo zertrümmerte und dabei viele wütend machte, aber den Durchbruch erzwang. Wim Taymans war der Versöhner, der ohne Drama vereinte, was vorher unvereinbar schien.
Und dazwischen die ruhigen Helden: Jaroslav Kysela, der mit ALSA das Fundament legte, auf dem alles steht. Paul Davis, der mit JACK die Pro-Audio-Welt erschuf und nebenbei den Linux-Kernel mit Realtime-Fähigkeiten ausstattete.
Linux hat dreissig Jahre gebraucht, um Audio professionell handhaben zu lönnen. Aber jetzt kann es das besser als jedes andere Desktop-Betriebssystem da draussen. Und das ist kein Zufall, sondern das Resultat von Streit, Frust, kontroversen Persönlichkeiten und einer Community, die nie aufgegeben hat, obwohl es viele gute Gründe dazu gegeben hätte.
Im nächsten Teil: zerlegen wir das Ganze technisch. Was macht ALSA heute eigentlich, was macht PipeWire, und wer zur Hölle ist WirePlumber? Wir schauen uns Sample-Rates, Buffer und Latenzen an, ich zeige dir, was Sinks, Sources und Nodes sind. Und am Ende verstehst du, warum dein Bluetooth-Headset im Gesprächs-Modus mono klingt.
Teil 2: Was passiert, wenn Linux Ton macht. Erscheint in zwei Tagen.
