v151 · Web Audio API

Production UX Pattern

The right renderSizeHint depends entirely on the use case. Three complete patterns — a low-latency instrument, a music player, and a voice conferencing app — each with the recommended hint, rationale, sample code, and a live probe that reads what your browser actually reports.

Recommended pattern — Instrument / DAW

BESTrenderSizeHint: "hardware" — lets the browser match the OS audio device's native block size. Lowest latency on most systems; avoids the 128-frame overhead when the device wants larger blocks.

OKrenderSizeHint: "default" (128 frames) — predictable, spec-compliant, good for AudioWorklet-based instruments that need precise buffer-by-buffer control.

AVOIDrenderSizeHint: 512 or larger — increases latency noticeably. A note played on a MIDI keyboard will feel sluggish.

// Low-latency instrument: let hardware decide
const ctx = new AudioContext({ renderSizeHint: 'hardware' });

// Fallback for older browsers that don't support renderSizeHint
const ctx2 = new AudioContext({
  ...(AudioContext.prototype.hasOwnProperty('renderSizeHint') && {
    renderSizeHint: 'hardware'
  })
});

console.log('baseLatency', ctx.baseLatency); // target: < 5ms
console.log('sampleRate', ctx.sampleRate); // typically 44100 or 48000

Creates a test AudioContext with renderSizeHint="hardware"

—

Recommended pattern — Music / podcast player

BESTrenderSizeHint: 512 or 1024 — larger quanta mean fewer callbacks per second, lower CPU overhead, better battery life. A 500ms buffer of pre-rendered audio hides any quantum size from the listener.

OKrenderSizeHint: "hardware" — still fine; the difference from a large hint is tiny for pre-buffered playback.

AVOIDrenderSizeHint: "default" (128 frames) for long-running players — the web audio thread wakes more often than needed, draining battery on mobile.

// Music player: larger quantum = fewer callbacks = better battery
const ctx = new AudioContext({ renderSizeHint: 512 });

// Connect source → EQ → gain → destination
const src = ctx.createMediaElementSource(audioElement);
const gain = ctx.createGain();
src.connect(gain);
gain.connect(ctx.destination);

Creates a test AudioContext with renderSizeHint=512

—

Recommended pattern — Voice / WebRTC conferencing

BESTrenderSizeHint: "hardware" — native device block size matches the OS audio pipeline. Avoids double-buffering between WebAudio and the OS audio server.

OKrenderSizeHint: "default" — predictable latency; good when the WebRTC jitter buffer is large enough to absorb the overhead.

AVOIDLarge hints (512+) for voice — end-to-end latency becomes perceptible. Human speech is disrupted at > 150ms round trip.

// Voice/WebRTC: match hardware, show permission UX on failure
async function createVoiceContext() {
  try {
    const stream = await navigator.mediaDevices.getUserMedia({ audio: true });
    const ctx = new AudioContext({ renderSizeHint: 'hardware' });
    const src = ctx.createMediaStreamSource(stream);
    // Process: noise gate, echo cancellation, compress…
    return { ctx, src, stream };
  } catch (e) {
    if (e.name === 'NotAllowedError') showPermissionBanner();
    else if (e.name === 'NotFoundError') showNoMicBanner();
    throw e;
  }
}

Creates a test AudioContext with renderSizeHint="hardware"

—

implementation reference

Need the exact API surface, compatibility boundaries, errors, lifecycle, and source links? Read the matching gendn reference ↗