v153 · web audio · performance
WebAudio: Configurable render quantum
Chrome 153 adds a renderSizeHint option to AudioContext and OfflineAudioContext, allowing developers to request a specific number of audio frames per render cycle — enabling trade-offs between latency and CPU overhead for their workload.
at a glance
| Shipped in | Chrome 153 (Enabled by default) |
|---|---|
| Status | Enabled by default (desktop, Android, WebView) |
| Specification | Web Audio API §renderQuantumSize · §renderSizeHint |
| Standards issues & PR | WebAudio PR #2469 · WebAudio issue #1503 |
| Standards positions | Mozilla #1407 · WebKit #662 |
| Blink intents & Bug | Intent to Prototype · Intent to Extend Experiment · Chromium Issue 40637820 |
| ChromeStatus | 5078190552907776 — WebAudio: Configurable render quantum |
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.
Syntax and WebIDL
// WebIDL definitions from the W3C Web Audio API specification:
enum AudioContextRenderSizeCategory {
"default",
"hardware"
};
dictionary AudioContextOptions {
// Existing options omitted...
(AudioContextRenderSizeCategory or unsigned long) renderSizeHint = "default";
};
dictionary OfflineAudioContextOptions {
// Existing options omitted...
(AudioContextRenderSizeCategory or unsigned long) renderSizeHint = "default";
};
partial interface BaseAudioContext {
readonly attribute unsigned long renderQuantumSize;
};
partial interface AudioWorkletGlobalScope {
readonly attribute unsigned long renderQuantumSize;
};
| Option / Member | Context | Type | Values |
|---|---|---|---|
renderSizeHint | AudioContextOptions, OfflineAudioContextOptions | (AudioContextRenderSizeCategory or unsigned long) |
integer → request that many frames per quantum"default" → use 128 frames (default baseline)"hardware" → let the User-Agent select optimal hardware quantum
|
renderQuantumSize | BaseAudioContext, AudioWorkletGlobalScope | unsigned long | The actual quantum size (in sample frames) selected by the browser for this context |
Inputs and outputs
Inputs: The renderSizeHint dictionary member accepts an unsigned integer (typically powers of two such as 32, 64, 128, 256, 512, 1024) or the string enum values "default" and "hardware". Passed during context construction via new AudioContext({ renderSizeHint }) or new OfflineAudioContext({ ..., renderSizeHint }).
Outputs: The renderQuantumSize attribute returns an unsigned integer reflecting the active render quantum size for the audio context. Inside an AudioWorkletProcessor, the worklet global scope exposes the identical renderQuantumSize value, determining the length of channel arrays in the process(inputs, outputs, parameters) callback.
Errors and lifecycle
Errors: Per the Web Audio API specification, passing an integer render-quantum size outside the supported range throws a NotSupportedError: §2.5 requires it for values outside the permitted range (1 up to 6× the sample rate). The renderSizeHint categories (AudioContextRenderSizeCategory: "default" or "hardware") are advisory and map onto a supported size. If a value of the wrong type is provided, standard WebIDL type conversion throws a TypeError.
Lifecycle: The render quantum size is fixed at context instantiation time and remains immutable for the lifetime of that AudioContext or OfflineAudioContext. Graph nodes and AudioWorklet processors instantiated within the context operate synchronously on blocks of renderQuantumSize frames throughout execution.
Examples
The following example demonstrates configuring low-latency synthesis, batch offline rendering, and accessing renderQuantumSize in main thread and worklet scopes:
// 1. Low-latency interactive synthesiser: request small quantum (lower latency, more CPU)
const ctx = new AudioContext({ renderSizeHint: 32 });
console.log(`Configured render quantum: ${ctx.renderQuantumSize} frames`);
// 2. Batch processor: request large quantum (less CPU callback overhead)
const offCtx = new OfflineAudioContext({
numberOfChannels: 2,
length: 44100 * 10, // 10 seconds
sampleRate: 44100,
renderSizeHint: 1024,
});
console.log(`Offline render quantum: ${offCtx.renderQuantumSize} frames`);
// 3. Requesting hardware-preferred quantum
const hwCtx = new AudioContext({ renderSizeHint: 'hardware' });
// 4. AudioWorkletProcessor handling variable render quantum sizes:
class DynamicQuantumProcessor extends AudioWorkletProcessor {
process(inputs, outputs) {
// globalThis.renderQuantumSize specifies frame buffer length per channel
const output = outputs[0];
const channelData = output[0];
for (let i = 0; i < channelData.length; i++) {
channelData[i] = 0.0;
}
return true;
}
}
Source: Web Audio API §renderQuantumSize; Web Audio PR #2469.
browser compatibility
Configurable render quantum is supported enabled by default in Chrome 153 and Chromium derivatives across desktop, Android, and WebView platforms. Other engine positions remain in progress as tracked by W3C Web Audio standards issues:
| Browser / Engine | Support | Notes & Evidence |
|---|---|---|
| Chrome (Chromium) 153+ | Enabled by default | Desktop, Android, WebView (ChromeStatus 5078190552907776) |
| Firefox (Gecko) | No formal signal | Spec change authored by Gecko engineer (Mozilla standards-positions #1407) |
| Safari (WebKit) | No formal signal | Issue open (WebKit standards-positions #662) |
security and privacy
- Timing resolution and fingerprinting: Audio render quantum sizes provide precise sub-millisecond hardware callback timing. To prevent cross-origin timing attacks and high-resolution fingerprinting, user agents may limit the minimum quantum size or restrict hardware buffer exposure to secure contexts.
- Resource consumption: Very small render quantum sizes (e.g. < 32 frames) increase thread interrupt frequency and CPU load. Implementations enforce lower bounds to prevent audio thread starvation and denial of service.