WebAudio: Configurable render quantum

at a glance

why it exists

The Web Audio API has always rendered audio in fixed 128-frame chunks (the render quantum). This gives a latency of about 2.9 ms at 44.1 kHz. While 128 frames is fine for most applications, it creates tensions at both ends of the spectrum:

• Low-latency instruments (synthesisers, live effects) would benefit from a smaller quantum (e.g. 32 frames) to cut round-trip latency, even at the cost of more CPU interrupts.
• Batch or background processing (audio fingerprinting, format conversion) runs more efficiently with a larger quantum (e.g. 1024 frames) to amortise callback overhead.

The renderSizeHint option lets the developer express a preference; the browser uses it as a hint, rounding to a supported size if necessary.

shape of the API

example

// Low-latency synth: request small quantum (lower latency, more CPU)
const ctx = new AudioContext({ renderSizeHint: 32 });
console.log(ctx.renderQuantumSize); // e.g. 32 or the next supported size

// Batch processor: request large quantum (less CPU, higher latency)
const offCtx = new OfflineAudioContext({
  numberOfChannels: 2,
  length: 44100 * 10,  // 10 seconds
  sampleRate: 44100,
  renderSizeHint: 1024,
});
console.log(offCtx.renderQuantumSize); // e.g. 1024

// Let the UA decide the optimal size
const hwCtx = new AudioContext({ renderSizeHint: 'hardware' });

// AudioWorklet: renderQuantumSize is exposed in the worklet processor
class MyProcessor extends AudioWorkletProcessor {
  process(inputs, outputs) {
    // this.context.renderQuantumSize tells you how many frames you get
    return true;
  }
}

browser support

see also

• Chrome Platform Status — WebAudio: Configurable render quantum
• Web Audio API — renderQuantumSize