Real-time audio in de browser: wat 2026 echt mogelijk maakt

De uitspraak “je kunt geen echte audio in de browser doen” klopte voor het grootste deel van het WebAudio-tijdperk. Dat hield op rond 2020 toen AudioWorklet uitkwam. Het werd ongemakkelijk onwaar toen WebGPU in 2023 verscheen en serieuze ML-inferentie van de CPU af kon halen. In 2026 doet browseraudio dingen waarvoor vijf jaar geleden een native app nodig was, en een paar dingen die echt nog steeds native vereisen.

Dit is de werkende kaart van de ondergrens en de bovengrens. Wat je vandaag met vertrouwen in de browser kunt uitbrengen, wat zich precies op het randje bevindt, en wat nog steeds een aparte codebase nodig heeft.

De vorm van het platform in 2026

Vijf API’s doen het werk:

• AudioContext + AudioNode-graaf. De klassieke WebAudio-primitieven. Ingebouwde nodes: gain, biquad, delay, compressor, convolver, analyser, panner. Prima voor “ik moet een geluid afspelen” en voor het analysewerk (FFT via AnalyserNode). Beperkt voor alles wat maatwerk is, omdat de graaf op het moment van instantiëren vastligt.
• AudioWorklet. De ontsnappingsroute. JavaScript of WebAssembly draaiend op een toegewijde audiothread, die buffers van 128 samples tegelijk verwerkt. Hier leven real-time DSP, synthese en analyse. AudioContext voor de routering, AudioWorklet voor het werk.
• MediaDevices.getUserMedia. Toegang tot de microfoon en andere invoer. Constraints-API voor sample rate, aantal kanalen, echo-onderdrukking, ruisonderdrukking. Gestandaardiseerd en consistent over browsers heen in 2026 op een manier die in 2020 nog niet bestond.
• MediaStreamTrack met AudioWorklet via MediaStreamTrackProcessor. Behandel een live track als een stroom audioframes die je kunt verwerken. De schone brug tussen opname en DSP.
• WebGPU. Algemene GPU-compute. De reden waarom audio-ML in de browser nu echt competitief is; zie de aparte sectie hieronder.

Daaromheen helpers: WebCodecs (encoderen/decoderen), Web Audio Stream Sink (rendering-paden met lage latency in moderne browsers), en de AudioSession-API voor integratie met mobiele platforms.

Latency: het kerngetal

Real-time audio wordt beoordeeld op round-trip-latency: de tijd vanaf het moment dat geluid de microfoon binnenkomt tot het verwerkte geluid uit de speakers komt. De ondergrenzen van 2026:

Platform	Round-trip-latency	Praktisch gebruik
Desktop Chrome / Edge	18–35 ms	Monitoring met effecten, tracking met lichte DSP
Desktop Safari	25–45 ms	Hetzelfde als Chrome maar iets slechter op macOS
Desktop Firefox	25–40 ms	Zelfde bereik als Safari
Android Chrome	35–80 ms	Hobbyproductie; geen professionele tracking
iOS Safari	30–60 ms	Met een marge strakker dan Android
Met buffergrootte 128 + toegewijde audio-interface	8–15 ms	Echt bruikbaar voor monitoring

Die laatste rij is van belang. Met eerlijke waarden voor WebAudio’s audioContext.baseLatency en audioContext.outputLatency kan een audio-interface die is geconfigureerd voor een buffer van 128 samples bij 48 kHz round-trip-latencies leveren die binnen de orde van grootte van JUCE-op-native liggen. De browsertaks is nu klein. Het is de OS-mixertaks die het grootste deel uitmaakt van wat overblijft.

Ter vergelijking: de equivalente native-app-ondergrens in 2026 met dezelfde interface is 4–8 ms. De browser zit op 2–3× de latency, niet 10×. Voor de meeste toepassingen doet dat verschil er niet toe. Voor live monitoring tijdens het tracken van vocalen telt het nog steeds.

Threading en jitter

AudioWorklet draait op audiothread-prioriteit. De buffer van 128 samples bij 48 kHz betekent dat de verwerking binnen 2,67 ms klaar moet zijn, anders krijg je een underrun (een hoorbare glitch). De audiothread doet geen GC, alloceert niet, en blokkeert niet op IO. Code in een AudioWorkletProcessor wordt aan dezelfde normen gehouden als code in een native audio-callback.

In de praktijk:

• Pure JavaScript-audiocode. Werkt prima voor DSP van gematigde complexiteit: een paar filters, een envelope follower, basale feature-extractie. De V8/JavaScriptCore-JITs zijn uitstekend op dit soort strakke numerieke lus. Allocaties zijn de vijand; de discipline is dezelfde als native.
• WebAssembly-audiocode. De standaard voor alles wat serieus is: volledige plugin-emulaties, FFT-intensieve analyse, volwassen DSP-bibliotheken geport vanuit C++. Buildpipelines (Emscripten, Rust + wasm-bindgen) zijn volwassen; de prestaties liggen binnen 1,2–1,5× van equivalente native code.
• SharedArrayBuffer + Atomics. Het transport om data tussen UI op de hoofdthread en DSP op de audiothread te krijgen zonder kopiëren. Vereist voor elke niet-triviale app. De COOP/COEP-headervereisten zijn een operationeel ongemak maar geen blokkade.

Het jitterverhaal is eerlijk: de runtimevariantie van de audiothread is goed onder controle op desktop, minder op mobiel. Apps die kogelvrij glitch-vrij gedrag nodig hebben, voegen een kleine jitterbuffer (5–10 ms) toe aan de uitvoerkant: dezelfde truc die native apps gebruiken op belaste systemen.

Wat er daadwerkelijk mogelijk is

Een niet-uitputtende lijst van dingen die werken in productiebrowsers in 2026:

Solide

• Multibandverwerkingsketens. EQ, compressie, gating, limiting. De standaard masteringketen draait comfortabel in één enkele AudioWorklet met een budget van enkele honderden microseconden per buffer.
• Real-time analyse. Spectrum, LUFS-metering (de AudioLab MixLab Analyzer doet dit in productie), toonsoortdetectie, beat-tracking, onset-detectie. Allemaal CPU-zuinig.
• Stemverwerking. Ruisonderdrukking, voice activity detection, microfoonverwerking: ruimschoots binnen het budget. De browser-ingebouwde NS/AEC (echoCancellation: true) is het luie “goed genoeg”; maatwerk-DSP voor producten die het nodig hebben.
• Synthese. Wavetable, FM, additief, subtractief: elke klassieke synthesetechniek. Polyfonie in de tientallen is comfortabel.
• Convolutiereverb. De ingebouwde ConvolverNode verwerkt willekeurige impulsresponsen. Lange IR’s (5+ seconden) werken via gepartitioneerde convolutie, wat de browserimplementaties nu correct doen.
• Loopen, slicen, time-stretchen, pitch-shiften. Phase-vocoder- en granulaire implementaties in WebAssembly zijn competitief met native equivalenten.
• MIDI-invoer en -uitvoer. Web MIDI is volwassen op Chromium-browsers; Safari kreeg het in 2024.

Op de rand van het haalbare

• Sample-nauwkeurige timing van lange arrangementen. Mogelijk, maar vereist zorgvuldige scheduling tegen audioContext.currentTime. De timing-primitieven van het webplatform zijn goed genoeg; de valkuilen zitten vooral in browsertab-throttling op inactieve tabbladen.
• Netwerkaudio met lage latency. WebRTC voor peer-to-peer is volwassen; het lastigere probleem is jitter en concealment op slechte netwerken. Maatwerktransporten via WebTransport zijn een opkomend pad.
• Plugin-hosting. AU/VST-hosting gaat niet gebeuren in de browser. WAM (Web Audio Modules) is een opkomende pluginstandaard, interessant maar een klein ecosysteem in 2026.
• Meerkanaals surround / Dolby Atmos-rendering. WebAudio ondersteunt in theorie tot 32 kanalen; in de praktijk is de routering op OS-niveau voor alles voorbij stereo platformafhankelijk en besturingssysteemafhankelijk.

Nog steeds echt alleen native

• Round-trip-latency onder 10 ms op consumentenmachines. De overhead van de OS-audiostack verdwijnt niet. Pro-audio-interfaces helpen; ze dichten het gat niet helemaal.
• Integratie op driverniveau met audio-interfaces. Maatwerk-mixerroutering, hardwarematige controllers, sample-nauwkeurige synchronisatie met externe apparaten. Browsers stellen dit niet beschikbaar en gaan dat niet doen.
• Audioverwerking op de achtergrond op vergrendelde mobiele apparaten. Het browsertabblad valt in slaap. Native apps niet.
• Audio-opname op OS-niveau van andere apps. Audioroutering op systeemniveau wordt bewust van de browser weggeschermd.

WebGPU en audio-ML

De grootste verschuiving van 2024–2026. WebGPU bracht GPU-compute naar de browser zonder WebGL’s grafische-enige beperkingen. Voor audio:

• Real-time inferentie van kleine tot middelgrote modellen. Bronscheiding, denoising, dereverberatie, super-resolutie: allemaal beschikbaar in de browser via ONNX Runtime Web of Transformers.js draaiend op WebGPU. De prestaties zijn competitief met desktopklasse CPU-inferentie.
• Grotere modellen (Whisper-large, MusicGen, Demucs in de grotere formaten) draaien nog steeds, maar met frame-voor-frame-batching die echte latency introduceert. Streaming-inferentie is het knelpunt, niet de ruwe doorvoer.
• Modelgroottes die comfortabel passen, liggen in het bereik van 50–500 MB. Groter dan dat en je vecht tegen cache-eviction.

Twee praktische patronen komen op in 2026:

1. Inferentie alleen op de edge. Het model leeft op de machine van de gebruiker, draait volledig in de browser, stuurt nooit audio ergens heen. De AudioLab-demo’s leunen om privacyredenen deze kant op.
2. Hybride. Goedkope voorbewerking in WebGPU; zware inferentie in een cloud-endpoint via WebTransport met een round-trip onder 100 ms. Zo zien de meeste productie-stemproducten er vandaag uit, en het cloudaandeel krimpt elk jaar.

De realiteit aan de buildkant

Het uitbrengen van een serieuze browseraudio-app in 2026 ziet er zo uit:

• Audiocode in Rust of C++, gecompileerd naar WebAssembly via Emscripten of wasm-bindgen. De buildpipeline komt overeen met wat een native app zou hebben.
• AudioWorklet-shim in TypeScript, die de WASM-module importeert en het audiothread-loodgieterswerk doet.
• UI op de hoofdthread in React/Vue/Svelte, die via SharedArrayBuffer met de audiothread praat.
• COOP/COEP-isolatie voor SharedArrayBuffer en WebGPU. Operationeel gevolg: third-party-iframes hebben coöperatieve headers nodig. Vervelend maar oplosbaar.
• PWA + Service Worker voor offline-bruikbare installaties. Echte audioproducten in 2026 worden installeerbaar uitgebracht.
• Workerpool voor zwaar werk buiten de audiothread: bestandsdecodering, analyse, ML-inferentie.

De buildketen is zover gerijpt dat een klein team een echt audioproduct kan uitbrengen zonder per platform een native buildpipeline te bezitten. Dat is de echte verschuiving van 2026, niet één enkele API.

Wat dit betekent voor productbeslissingen

Een werkende vuistregel:

Kies browser-first tenzij je specifiek (a) round-trip-latency onder 10 ms, (b) plugin-hosting, (c) achtergrondaudio wanneer het tabblad gesloten is, of (d) diepe audioroutering op OS-niveau nodig hebt.

Vijf jaar geleden was “browser-first” een beperkte keuze, waarbij je aanzienlijke compromissen accepteerde voor het gemak van distributie. In 2026 is browser-first een concurrerende keuze voor een breed spectrum aan audioproducten. Distributie is eenvoudiger, het platform is goed genoeg, en de installatietrechter concurreert niet met de marktplaatsen voor native apps.

Voor AudioLab worden alle zeven labs vanuit het ontwerp browser-first uitgebracht. De afwegingen die we accepteren (een iets hogere ondergrens-latency, geen plugin-hosting) zijn niet relevant voor waar de labs voor zijn. Maak voor jouw product de eerlijke afweging van wat je werkelijk nodig hebt voordat je je vastlegt op het een of het ander.

Probeer de AudioLab-demo’s → · WebAudio vs native diepe duik → · Methodologie →