Echtzeit-Audio im Browser: was 2026 tatsächlich möglich macht

Der Satz „Echte Audioverarbeitung im Browser geht nicht” stimmte für den Großteil der WebAudio-Ära. Er hörte um 2020 herum auf zu stimmen, als AudioWorklet erschien. Er wurde unangenehm falsch, als WebGPU 2023 erschien und ernsthafte ML-Inferenz von der CPU wegholen konnte. 2026 macht Browser-Audio Dinge, für die vor fünf Jahren eine native App nötig gewesen wäre, und ein paar Dinge, die tatsächlich noch immer Native erfordern.

Dies ist die praktische Landkarte von Unter- und Obergrenze. Was du heute mit Zuversicht im Browser ausliefern kannst, was direkt an der Kante liegt, und was nach wie vor eine eigene Codebasis braucht.

Die Gestalt der Plattform im Jahr 2026

Fünf APIs erledigen die Arbeit:

• AudioContext + AudioNode-Graph. Die klassischen WebAudio-Primitive. Eingebaute Nodes: gain, biquad, delay, compressor, convolver, analyser, panner. Gut geeignet für „ich muss einen Klang abspielen” und für die Analyseseite (FFT via AnalyserNode). Begrenzt für alles Maßgeschneiderte, weil der Graph zum Zeitpunkt der Instanziierung festgelegt wird.
• AudioWorklet. Die Notausstiegsluke. JavaScript oder WebAssembly, das auf einem dedizierten Audio-Thread läuft und Puffer von jeweils 128 Samples verarbeitet. Hier leben Echtzeit-DSP, Synthese und Analyse. AudioContext für das Routing, AudioWorklet für die Arbeit.
• MediaDevices.getUserMedia. Zugriff auf Mikrofon und andere Eingaben. Constraints-API für Sample Rate, Kanalanzahl, Echounterdrückung, Rauschunterdrückung. 2026 browserübergreifend standardisiert und konsistent auf eine Weise, wie es 2020 nicht der Fall war.
• MediaStreamTrack mit AudioWorklet via MediaStreamTrackProcessor. Behandle einen Live-Track als einen Strom von Audioframes, den du verarbeiten kannst. Die saubere Brücke zwischen Aufnahme und DSP.
• WebGPU. Universelle GPU-Compute. Der Grund, warum In-Browser-Audio-ML jetzt wirklich konkurrenzfähig ist, siehe den eigenen Abschnitt weiter unten.

Drumherum Helfer: WebCodecs (Encoding/Decoding), Web Audio Stream Sink (Rendering-Pfade mit niedriger Latenz in modernen Browsern) und die AudioSession-API zur Integration mit mobilen Plattformen.

Latenz: die Schlüsselzahl

Echtzeit-Audio wird an der Round-Trip-Latenz gemessen: der Zeit vom Eintreffen des Klangs am Mikrofon bis zur Ausgabe des verarbeiteten Klangs über die Lautsprecher. Die Untergrenzen von 2026:

Plattform	Round-Trip-Latenz	Praktischer Einsatz
Desktop Chrome / Edge	18–35 ms	Monitoring mit Effekten, Tracking mit leichtem DSP
Desktop Safari	25–45 ms	Wie Chrome, aber unter macOS etwas schlechter
Desktop Firefox	25–40 ms	Gleicher Bereich wie Safari
Android Chrome	35–80 ms	Hobby-Produktion; kein professionelles Tracking
iOS Safari	30–60 ms	Mit Abstand straffer als Android
Mit Puffergröße 128 + dediziertem Audio-Interface	8–15 ms	Wirklich brauchbar für Monitoring

Diese letzte Zeile ist entscheidend. Mit ehrlichen Werten für WebAudios audioContext.baseLatency und audioContext.outputLatency kann ein Audio-Interface, das auf einen 128-Sample-Puffer bei 48 kHz konfiguriert ist, Round-Trip-Latenzen liefern, die im Bereich von JUCE-auf-Native liegen. Die Browser-Steuer ist jetzt gering. Es ist die OS-Mixer-Steuer, die den größten Teil dessen ausmacht, was übrig bleibt.

Zum Vergleich: Die entsprechende Native-App-Untergrenze liegt 2026 mit demselben Interface bei 4–8 ms. Der Browser liegt beim 2–3-Fachen der Latenz, nicht beim 10-Fachen. Für die meisten Anwendungsfälle spielt dieser Abstand keine Rolle. Für Live-Monitoring beim Tracking von Vocals spielt er nach wie vor eine Rolle.

Threading und Jitter

AudioWorklet läuft mit Audio-Thread-Priorität. Der 128-Sample-Puffer bei 48 kHz bedeutet, dass die Verarbeitung innerhalb von 2,67 ms abgeschlossen sein muss, sonst gibt es einen Underrun (eine hörbare Störung). Der Audio-Thread betreibt keine GC, alloziert nicht und blockiert nicht auf IO. Code in einem AudioWorkletProcessor wird an denselben Maßstäben gemessen wie Code in einem nativen Audio-Callback.

In der Praxis:

• Reiner JavaScript-Audiocode. Funktioniert gut für DSP mittlerer Komplexität: ein paar Filter, ein Envelope Follower, grundlegende Feature-Extraktion. Die V8-/JavaScriptCore-JITs sind bei dieser Art enger numerischer Schleife hervorragend. Allokationen sind der Feind; die Disziplin ist dieselbe wie bei Native.
• WebAssembly-Audiocode. Der Standard für alles Ernsthafte: vollständige Plugin-Emulationen, FFT-lastige Analyse, ausgereifte DSP-Bibliotheken, portiert aus C++. Build-Pipelines (Emscripten, Rust + wasm-bindgen) sind ausgereift; die Performance liegt innerhalb des 1,2–1,5-Fachen von äquivalentem nativem Code.
• SharedArrayBuffer + Atomics. Der Transportweg, um Daten zwischen der UI auf dem Hauptthread und dem DSP auf dem Audio-Thread ohne Kopieren auszutauschen. Erforderlich für jede nicht-triviale App. Die COOP/COEP-Header-Anforderungen sind ein betrieblicher Aufwand, aber kein Hindernis.

Die Jitter-Geschichte ist ehrlich: Die Laufzeitvarianz des Audio-Threads ist auf dem Desktop gut beherrscht, auf Mobilgeräten weniger. Apps, die kugelsicher störungsfreies Verhalten brauchen, fügen auf der Ausgabeseite einen kleinen Jitter-Puffer (5–10 ms) hinzu, derselbe Trick, den native Apps auf ausgelasteten Systemen verwenden.

Was tatsächlich möglich ist

Eine nicht erschöpfende Liste von Dingen, die 2026 in Produktionsbrowsern funktionieren:

Solide

• Mehrband-Verarbeitungsketten. EQ, Kompression, Gating, Limiting. Die übliche Mastering-Kette läuft komfortabel in einem einzigen AudioWorklet mit einem Budget von einigen hundert Mikrosekunden pro Puffer.
• Echtzeit-Analyse. Spektrum, LUFS-Metering (der AudioLab MixLab Analyzer macht das in Produktion), Tonarterkennung, Beat-Tracking, Onset-Erkennung. Allesamt CPU-genügsam.
• Sprachverarbeitung. Rauschunterdrückung, Voice Activity Detection, Mikrofonverarbeitung, locker im Budget. Die browsereigene NS/AEC (echoCancellation: true) ist das bequeme „gut genug”; maßgeschneidertes DSP für Produkte, die es brauchen.
• Synthese. Wavetable, FM, additiv, subtraktiv: jede klassische Synthesetechnik. Polyfonie in der Größenordnung von Dutzenden ist komfortabel.
• Faltungshall (Convolution Reverb). Die eingebaute ConvolverNode verarbeitet beliebige Impulsantworten. Lange IRs (5+ Sekunden) funktionieren über partitionierte Faltung, was die Browser-Implementierungen mittlerweile korrekt umsetzen.
• Loopen, Slicen, Time-Stretching, Pitch-Shifting. Phase-Vocoder- und granulare Implementierungen in WebAssembly sind mit nativen Äquivalenten konkurrenzfähig.
• MIDI-Eingang und -Ausgang. Web MIDI ist auf Chromium-Browsern ausgereift; Safari erhielt es 2024.

Am Rand des Machbaren

• Sample-genaues Timing langer Arrangements. Möglich, erfordert aber sorgfältiges Scheduling gegen audioContext.currentTime. Die Timing-Primitive der Web-Plattform sind gut genug; die Fallstricke liegen meist im Browser-Tab-Throttling bei inaktiven Tabs.
• Netzwerk-Audio mit niedriger Latenz. WebRTC für Peer-to-Peer ist ausgereift; das schwierigere Problem sind Jitter und Concealment in schlechten Netzen. Maßgeschneiderte Transporte via WebTransport sind ein aufkommender Weg.
• Plugin-Hosting. AU/VST-Hosting wird im Browser nicht passieren. WAM (Web Audio Modules) ist ein aufkommender Plugin-Standard, interessant, aber 2026 ein kleines Ökosystem.
• Mehrkanal-Surround / Dolby-Atmos-Rendering. WebAudio unterstützt theoretisch bis zu 32 Kanäle; in der Praxis ist das Routing auf OS-Ebene für alles jenseits von Stereo plattform- und betriebssystemabhängig.

Nach wie vor wirklich nur Native

• Round-Trip-Latenz unter 10 ms auf Consumer-Maschinen. Der Overhead des OS-Audio-Stacks verschwindet nicht. Pro-Audio-Interfaces helfen; sie schließen die Lücke nicht vollständig.
• Integration auf Treiberebene mit Audio-Interfaces. Maßgeschneidertes Mixer-Routing, hardwarebasierte Steuerflächen, sample-genaue Synchronisation mit externen Geräten. Browser legen das nicht offen und werden es nicht tun.
• Audioverarbeitung im Hintergrund auf gesperrten Mobilgeräten. Der Browser-Tab geht schlafen. Native Apps nicht.
• Audioaufnahme auf OS-Ebene von anderen Apps. Audio-Routing auf Systemebene ist bewusst vom Browser abgeschottet.

WebGPU und Audio-ML

Die größte Verschiebung von 2024–2026. WebGPU brachte GPU-Compute in den Browser, ohne WebGLs Beschränkung auf reine Grafik. Für Audio:

• Echtzeit-Inferenz kleiner bis mittelgroßer Modelle. Quellentrennung, Denoising, Dereverberation, Super-Resolution: alle im Browser verfügbar über ONNX Runtime Web oder Transformers.js, laufend auf WebGPU. Die Performance ist mit CPU-Inferenz der Desktop-Klasse konkurrenzfähig.
• Größere Modelle (Whisper-large, MusicGen, Demucs in den größeren Größen) laufen weiterhin, aber mit Frame-für-Frame-Batching, das echte Latenz einführt. Streaming-Inferenz ist der Engpass, nicht der reine Durchsatz.
• Modellgrößen, die komfortabel passen, liegen im Bereich von 50–500 MB. Größer als das, und du kämpfst gegen Cache-Eviction.

Zwei praktische Muster zeichnen sich 2026 ab:

1. Reine Edge-Inferenz. Das Modell lebt auf der Maschine des Nutzers, läuft vollständig im Browser, sendet niemals Audio irgendwohin. Die AudioLab-Demos tendieren aus Datenschutzgründen in diese Richtung.
2. Hybrid. Günstige Vorverarbeitung in WebGPU; schwere Inferenz in einem Cloud-Endpunkt via WebTransport mit einer Round-Trip-Zeit unter 100 ms. So sehen die meisten Produktions-Sprachprodukte heute aus, und der Cloud-Anteil schrumpft Jahr für Jahr.

Die Realität auf der Build-Seite

Eine ernsthafte Browser-Audio-App im Jahr 2026 auszuliefern sieht so aus:

• Audiocode in Rust oder C++, kompiliert zu WebAssembly via Emscripten oder wasm-bindgen. Die Build-Pipeline entspricht dem, was eine native App hätte.
• AudioWorklet-Shim in TypeScript, der das WASM-Modul importiert und die Audio-Thread-Verkabelung übernimmt.
• UI auf dem Hauptthread in React/Vue/Svelte, die über SharedArrayBuffer mit dem Audio-Thread kommuniziert.
• COOP/COEP-Isolation für SharedArrayBuffer und WebGPU. Betriebliche Konsequenz: Third-Party-iframes brauchen kooperative Header. Lästig, aber lösbar.
• PWA + Service Worker für offline-fähige Installationen. Echte Audioprodukte werden 2026 installierbar ausgeliefert.
• Worker-Pool für rechenintensive Aufgaben außerhalb des Audio-Threads: Dateidekodierung, Analyse, ML-Inferenz.

Die Build-Kette ist so weit gereift, dass ein kleines Team ein echtes Audioprodukt ausliefern kann, ohne pro Plattform eine native Build-Pipeline zu besitzen. Das ist die eigentliche Verschiebung von 2026, nicht irgendeine einzelne API.

Was das für Produktentscheidungen bedeutet

Eine praktische Faustregel:

Wähle Browser-First, es sei denn, du brauchst speziell (a) Round-Trip-Latenz unter 10 ms, (b) Plugin-Hosting, (c) Hintergrund-Audio, wenn der Tab geschlossen ist, oder (d) tiefes Audio-Routing auf OS-Ebene.

Vor fünf Jahren war „Browser-First” eine eingeschränkte Wahl, man akzeptierte erhebliche Kompromisse zugunsten der Distributionsbequemlichkeit. 2026 ist Browser-First eine konkurrenzfähige Wahl für ein breites Spektrum an Audioprodukten. Die Distribution ist einfacher, die Plattform ist gut genug, und der Installations-Funnel konkurriert nicht mit den Marktplätzen für native Apps.

Bei AudioLab werden alle sieben Labs konzeptbedingt Browser-First ausgeliefert. Die Kompromisse, die wir akzeptieren (eine etwas höhere Untergrenze-Latenz, kein Plugin-Hosting), sind irrelevant für das, wofür die Labs da sind. Mach für dein Produkt die ehrliche Abrechnung dessen, was du wirklich brauchst, bevor du dich auf das eine oder das andere festlegst.

Probiere die AudioLab-Demos → · WebAudio vs. Native im Detail → · Methodik →