Building Low-Latency Synthesizers with AudioWorklet

This article explores how the Web Audio API's AudioWorklet interface enables web engineers to build high-performance, low-latency synthesizers directly in the browser. By executing custom digital signal processing (DSP) code off the browser's main thread, AudioWorklet eliminates audio glitches, guarantees sample-accurate timing, and unlocks near-native sound synthesis capabilities within modern web applications.

The Problem with Legacy Web Audio Processing

Before the introduction of AudioWorklet, web-based custom synthesis relied on the ScriptProcessorNode. This interface executed audio processing code directly on the browser's main UI thread. Because the main thread also handles Document Object Model (DOM) updates, CSS rendering, style calculations, and general JavaScript execution, the audio pipeline was frequently interrupted.

When heavy operations occurred on the main thread, the audio buffer was starved, leading to dropped samples, audible clicks, pops, and high latency due to required large buffer sizes. Additionally, the memory management and non-deterministic nature of JavaScript's garbage collector regularly caused unacceptable jitter for real-time musical instruments.

Dedicated Audio Rendering Thread

The primary architectural advantage of AudioWorklet is thread isolation. An AudioWorklet runs within an AudioWorkletGlobalScope, an execution context completely decoupled from the main browser thread.

By operating directly on the audio rendering thread, the synthesizer's DSP loop avoids contention with user interface operations. Even if the web page performs complex animations, loads large network resources, or executes heavy JavaScript logic, the audio generation loop continues uninterrupted, maintaining steady, predictable output.

Ultra-Low Buffer Sizes and Sample-Accurate Timing

Latency in digital audio is fundamentally tied to buffer size: smaller buffers produce lower latency but require tighter deadlines. AudioWorklet is designed around a fixed rendering quantum of 128 frames (approximately 2.9 milliseconds at a 44.1 kHz sample rate).

Within an AudioWorkletProcessor subclass, the developer implements a synchronous process() method:

class SynthProcessor extends AudioWorkletProcessor {
  process(inputs, outputs, parameters) {
    const output = outputs[0];
    const channel = output[0];

    for (let i = 0; i < channel.length; ++i) {
      // Direct sample calculation for synthesis
      channel[i] = Math.sin(this.phase);
      this.phase += this.phaseIncrement;
    }

    return true;
  }
}
registerProcessor('synth-processor', SynthProcessor);

Because this method executes synchronously at the hardware buffer level, engineers achieve sub-5-millisecond processing latency. This is essential for interactive musical instruments, where delays exceeding 10 to 15 milliseconds between a user pressing a key and hearing a sound feel sluggish and unnatural.

Thread-Safe Parameter Modulation and Communication

Synthesizers require dynamic parameter control for components like envelopes, filters, and low-frequency oscillators (LFOs). AudioWorklet handles this through two mechanisms:

  1. AudioParam Automation: Developers can declare custom AudioParam descriptors inside the processor. The browser's native audio engine handles parameter interpolation (a-rate for per-sample changes, or k-rate for per-block changes), ensuring modulation occurs with sample accuracy without needing manual thread synchronization.
  2. MessagePort for Control Data: For MIDI events, note-on/note-off triggers, and patch changes, the companion AudioWorkletNode on the main thread communicates with the AudioWorkletProcessor using an asynchronous postMessage pipeline. This architecture ensures control signals reach the synthesizer without blocking the audio thread.

Garbage Collection Avoidance and WebAssembly Integration

Achieving sustained low-latency requires zero-allocation loops. Inside the process() method, arrays are passed by reference and reused by the underlying engine rather than reallocated on each tick. This ensures the JavaScript engine does not trigger garbage collection sweeps that could pause the audio pipeline.

For more complex synthesis engines—such as physical modeling, multi-voice FM, or analog circuit emulation—AudioWorklet supports WebAssembly (Wasm). Developers can compile DSP code written in C, C++, or Rust into a Wasm binary, load it directly into the AudioWorkletGlobalScope, and execute it inside the process() callback. This combines native computational speed and deterministic memory management with the accessibility of the open web.