Browser-Audio-Technik: Der Gesamtüberblick — Web Audio API, WebAssembly und der Stand der Technik
Zuletzt aktualisiert: 13. Juni 2026 · Autor: Kotaro Asahina (Gründer von Kuon, Toningenieur)
Quick Answer
Stand 2026 ermöglichen fünf Techniken professionelle Audioverarbeitung im Browser: Web Audio API (W3C, 2011), WebAssembly (W3C-Standard 2017, ~90 % native Geschwindigkeit), AudioWorklet (3–10 ms Latenz), SharedArrayBuffer und die File System Access API (Dateien im Multi-GB-Bereich). Kuon vereint alle fünf und liefert weltweit erstmals browserbasiertes DDP-Parsing, DSD-zu-PCM-Wandlung und KI-Stem-Trennung — Arbeitsabläufe, die zuvor Desktop-Programmen vorbehalten waren.
Kennzahlen
- Web Audio API kodifiziert
- 2011
- WebAssembly standardisiert
- 2017
- AudioWorklet-Latenz
- 3–10 ms
- getUserMedia-Eingangslatenz
- 20–50 ms
- WebGPU standardisiert
- 2023
- Web MIDI API Recommendation
- 2022
- Wasm-Geschwindigkeit (vs. nativ)
- ~90 %
- File System Access, max. Datei
- ~Dutzende GB
Was ist browserbasierte Audioverarbeitung?
Browserbasierte Audioverarbeitung ist das Gebiet, auf dem Web Audio API, WebAssembly, AudioWorklet, File System Access API und weitere Webstandards zusammen Audioarbeit liefern, die installationsfrei, OS-unabhängig und Privacy First ist. Derselbe Code läuft in Chrome, Safari, Firefox und Edge — auf Mac, Windows, Linux und Chromebook.
Bis etwa 2014 galt: Browser schaffen nur Leichtgewichtiges. WebAssembly und AudioWorklet haben diese Annahme umgeschrieben — heute lassen sich professionelle DAWs, Stem-Trennung, Mastering und High-Resolution-Konvertierung im Browser umsetzen.
Grundlagen der Web Audio API
Die Web Audio API ist die JavaScript-API, deren Standardisierung das W3C 2011 begann — für Erzeugung, Verarbeitung und Analyse von Audio im Browser. Die Kernobjekte:
Die Revolution, die WebAssembly dem Audio brachte
WebAssembly (Wasm), 2017 vom W3C standardisiert, ist ein binäres Ausführungsformat mit nahezu nativer Geschwindigkeit im Browser. Code in C, C++ oder Rust lässt sich nach Wasm kompilieren — Jahrzehnte gewachsener Audiobibliotheken (FFTW, libsoxr, librosa und mehr) wurden so in den Browser portierbar.
Wasm läuft mit rund 90 % nativer Geschwindigkeit und ist 5–20× schneller als JavaScript. FFTs, Resampling, Codecs und Stem-Trennung — Lasten, die in JavaScript schlicht nicht machbar waren — wurden mit Wasm praktikabel. Nahezu jeder Qualitätssprung der Browser-Audioverarbeitung geht auf Wasm zurück.
Große Dateien per File System Access API
Klassische Blob/ArrayBuffer-Verarbeitung war bei rund 2 GB Speicher gedeckelt — zu wenig für mehrere CDs DSD-Audio oder lange Live-Mitschnitte. Die File System Access API (Chrome 86+, 2020) hebt diese Schranke durch direkte Lese- und Schreibzugriffe auf der Festplatte auf.
Der Kuon DSD CONVERTER nutzt diese API, um DSD512-Dateien über 5 GB direkt im Browser im Streaming zu verarbeiten — ein Arbeitsablauf, der zuvor nur reiner Desktop-Software offenstand.
Bemerkenswerte Beispiele
Was im Browser möglich ist
- Tonhöhenerkennung: YIN, pYIN, CREPE — im Browser (z. B. Kuon INTONATION)
- FFT und Spektrumanalyse: AnalyserNode mit Echtzeit-8192-Punkte-FFT
- Echtzeit-DSP: AudioWorklet mit 3–10 ms Latenz für eigene Verarbeitung
- Quellentrennung: cloudgestützt (Kuon SEPARATOR)
- DSD/PCM-Wandlung: hochpräzise Rust+Wasm-Filterung (Kuon DSD CONVERTER)
- Mastering-Analyse: LUFS-, True-Peak- und Loudness-Range-Messung
- DDP/SACD-Analyse: vollständiges Parsen der Industrieformate per Binärparser
Die Vorteile des Browser-Audios
Vier wesentliche Vorteile. Erstens: keine Installation — URL öffnen und loslegen; am anderen PC dort weitermachen, wo man aufgehört hat. Zweitens: plattformübergreifend — identisches Verhalten auf Mac, Windows, Linux, Chromebook und iPad. Drittens: Teilbarkeit — ein Link genügt, um Projekt oder Stück zu teilen. Viertens: Privacy First — Dateien können im Browser-Speicher bleiben und erreichen nie einen Server.
Die Grenzen
Beim professionellen Studio-Tracking und bei Echtzeit-MIDI behält die native DAW den Vorzug — für Mastering, Analyse, Konvertierung und Ausbildung sind browserbasierte Plattformen heute jedoch mehr als tragfähig.
Was kommt: WebGPU, WebCodecs und Audio Worklet
Drei Techniken prägen die nächste Welle. WebGPU (2023 standardisiert) öffnet dem Browser die GPU-Parallelität — und beschleunigt neuronale Quellentrennung, große FFTs und Echtzeit-Spektralsynthese. Die WebCodecs API (seit 2022) gewährt Low-Level-Zugriff auf Video- und Audio-Codecs und macht Echtzeit-Enkodierung und -Dekodierung von Opus, FLAC und AAC effizienter. Die fortgesetzte Audio-Worklet-Entwicklung, kombiniert mit SharedArrayBuffer, ermöglicht komplexere Echtzeit-DSP-Ketten im Browser.
Die Browser-Weltpremieren von Kuon
Stand 2026 hat Kuon mehrere Weltpremieren im Browser-Audio ausgeliefert:
- DDP PLAYER: weltweit erste browserbasierte DDP-Analyse mit Gap Listen
- DSD CONVERTER: Rust+Wasm + Blackman-Sinc-FIR — DSD-zu-PCM in Profi-Software-Qualität
- INTONATION: Cent-genaues Echtzeit-Pitch-Tracking per YIN-Algorithmus
- AUDIO MIRROR: Referenz-A/B-Vergleich mit Privacy-First-Design
- SEPARATOR: KI-Stem-Trennung (Cloud-Verarbeitung)
- Insgesamt 44 Apps sowie ein kostenloses Journal, verfügbar in 4 Sprachen
Technische Tiefenanalysen versammelt die Seite Weltpremieren von Kuon.
Referenzen für Entwickler
- W3C Web Audio API Spezifikation:
https://www.w3.org/TR/webaudio/ - MDN — Web Audio API:
https://developer.mozilla.org/en-US/docs/Web/API/Web_Audio_API - WebAssembly offiziell:
https://webassembly.org/ - Google Developers — Audio Worklet:
https://developer.chrome.com/blog/audio-worklet/
Häufige Fragen
Ist professionelle Audioverarbeitung im Browser wirklich möglich?
Ja. WebAssembly portiert in C/C++ geschriebene Industriebibliotheken mit über 90 % nativer Geschwindigkeit in den Browser, und AudioWorklet erreicht Latenzen von 3–10 ms. SEPARATOR (KI-Stem-Trennung), DSD CONVERTER und AUDIO MIRROR von Kuon laufen alle im Browser — in Qualität auf Augenhöhe mit reiner Desktop-Software.
Seit wann gibt es die Web Audio API?
Die Standardisierung beim W3C begann 2011; die großen Browser implementierten sie ab etwa 2014. Heute ist sie in allen modernen Browsern verfügbar — Chrome, Safari, Firefox und Edge. AudioWorklet (für latenzarme Verarbeitung) wurde ab 2018 schrittweise eingeführt und ist heute Standard.
Was ist WebAssembly?
WebAssembly (Wasm) ist ein 2017 vom W3C standardisiertes binäres Ausführungsformat, das im Browser mit nahezu nativer Geschwindigkeit läuft. Code in C, C++ oder Rust lässt sich nach Wasm kompilieren und im Browser ausführen. In der Audioverarbeitung dient es FFTs, Filterung, Codecs und anderen Lasten, die native Geschwindigkeit verlangen.
Was ist AudioWorklet?
AudioWorklet ist Teil der Web Audio API und läuft auf einem eigenen Audio-Thread. Es arbeitet in Echtzeit unabhängig vom Hauptthread und erreicht Latenzen von etwa 3–10 ms. Es ist der Nachfolger des veralteten ScriptProcessorNode und die zentrale Technik moderner Browser-Audioverarbeitung.
Gibt es Dateigrößen-Grenzen bei der Browser-Audioverarbeitung?
Früher lag die Grenze Blob/ArrayBuffer-basierter Verarbeitung bei rund 2 GB Speicher. Die File System Access API (Chrome 86+, 2020) hob diese Schranke auf: direkte Lese- und Schreibzugriffe auf große Dateien (Dutzende GB) auf der Festplatte. Der Kuon DSD CONVERTER verarbeitet damit Dateien über 5 GB.
Welche Nachteile hat die Browser-Audioverarbeitung?
Drei wesentliche: (1) Die Echtzeitleistung liegt noch hinter nativen DAWs (für latenzkritisches Tracking nicht ideal), (2) GPU-beschleunigte Abläufe reifen erst mit WebGPU heran, (3) die Abtastrate der Web Audio API hängt von den OS-Einstellungen ab. Für nicht-echtzeitkritische Arbeit — Mastering, Analyse, Konvertierung — sind Browser mit nativer Software konkurrenzfähig.
Sind Soundtrap und Splice browserbasierte Audio-Plattformen?
Ja. Soundtrap (Spotify, übernommen 2017) und Splice (USA) sind Musikproduktions-Plattformen im Browser. BandLab und Ableton Note Web nutzen ähnliche Technik. Kuon gehört zu dieser Linie — mit Fokus auf Musikausbildung, Konvertierung und Analyse.
Wie wird WebGPU die Browser-Audioverarbeitung beeinflussen?
WebGPU (2023 in Chrome standardisiert) öffnet die GPU-Parallelverarbeitung für den Browser. Im Audio beschleunigt das große FFTs, neuronale Quellentrennung und Echtzeitanalyse. Kuon erforscht, die SEPARATOR-Verarbeitung künftig auf WebGPU zu heben.
Was ist SharedArrayBuffer?
SharedArrayBuffer ist ein Speicherbereich, den mehrere JavaScript-Threads teilen können. In Kombination mit AudioWorklet ermöglicht er schnellen Datenaustausch zwischen Haupt- und Audio-Thread. Wegen der Spectre-Lücken zeitweise deaktiviert, ist er heute über Cross-Origin-Isolation-Header (COOP/COEP) wieder verfügbar.
Ist MIDI-Ein-/Ausgabe im Browser möglich?
Ja. Die Web MIDI API (W3C Candidate Recommendation 2015, Recommendation 2022) lässt Browser direkt mit USB- und Bluetooth-MIDI-Geräten kommunizieren. Mehrere Musik-Apps von Kuon nutzen diese API.
Wie geht der Browser mit Mikrofoneingang um?
Die getUserMedia API (Teil von WebRTC) gewährt mit Nutzererlaubnis Zugriff auf das Mikrofon. Die Latenz liegt bei rund 20–50 ms — ausreichend für Echtzeit-Stimmgeräte und Aufnahme-Apps. TUNER, INTONATION und die Aufnahme-Apps von Kuon nutzen diese API.
Welche Weltpremieren hat Kuon im Browser umgesetzt?
Die wichtigsten: (1) der browserbasierte DDP PLAYER (vollständiges Parsen von CD-Mastering-Dateien plus Gap Listen), (2) der Browser-DSD-CONVERTER (Rust+Wasm + Blackman-Sinc-FIR, auf Profi-Software-Niveau), (3) AUDIO MIRROR (Referenz-A/B-Vergleich mit Privacy-First-Design) und (4) die Echtzeit-INTONATION-Analyse (Cent-genaues Pitch-Tracking per YIN-Algorithmus).
参考文献・出典
- W3C Web Audio API 1.1 Spezifikation— Aktuelle Spezifikation (Revision 2024)
- MDN — Web Audio API— Offizielle Mozilla-Tutorials
- WebAssembly offiziell— Spezifikation und Implementierungen
- Google Developers — Audio Worklet— Latenzarme Verarbeitung erklärt
- Web Audio Conference Proceedings— Akademische Konferenzbeiträge