Intent to Extend Experiment: WebAudio: Configurable render quantum

[Chromestatus]

Contact emails

hong...@google.com, mjwi...@chromium.org

Specification

https://webaudio.github.io/web-audio-api/#dom-baseaudiocontext-renderquantumsize

Design docs

No information provided
https://github.com/WebAudio/web-audio-api/blob/main/explainer/user-selectable-render-size.md

Summary

Adds an optional renderSizeHint to AudioContext and OfflineAudioContext. This allows developers to customize the WebAudio render quantum size by passing a specific integer, use the default of 128 frames by omitting the hint or passing "default", or request that the User-Agent select an optimal size by specifying "hardware".

Blink component

Blink>WebAudio

Web Feature ID

web-audio

TAG review

No information provided

TAG review status

Issues addressed

Origin Trial Name

WebAudio Configurable Render Quantum

Goals for experimentation

Validate performance improvement gained by matching render quantum size to software buffer sizes when using a numeric renderSizeHint. Verify actual audio processing output is unchanged when using a numeric renderSizeHint. We have a primary partner for this Origin Trial, and we would like to see if the performance and ergonomics of the API satisfy this partner's need. This partner is not going to use the "hardware" hint, and we think that it is still valuable to conduct an Origin Trial to gather feedback on the rest of the API.

Chromium Trial Name

WebAudioConfigurableRenderQuantum

Origin Trial documentation link

https://webaudio.github.io/web-audio-api/#dom-audiocontextoptions-rendersizehint

WebFeature UseCounter name

kWebAudioRenderSizeHint

Risks

Interoperability and Compatibility

Low. The feature is already specified.

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/1407) A Firefox developer wrote the specification change (https://github.com/WebAudio/web-audio-api/pull/2469).

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/662)

Web developers: Positive (https://github.com/WebAudio/web-audio-api/issues/1503) Developers have requested a way to increase the render quantum size, and are looking forward to the feature being implemented.

Other signals:

Ergonomics

An identified use case of this feature is to match buffer sizes used by other Chromium audio APIs, in order to improve performance.

Activation

There is an ongoing privacy discussion about how to mitigate fingerprinting concerns around the "hardware" hint (https://github.com/WebAudio/web-audio-api/issues/2659). The "hardware" hint as implemented in Chromium currently will always return the default 128 render quantum size, which exposes no user information. This is allowed by the spec, which says "It is a hint that might not be honored."

Security

There is concern that a very low render quantum size could allow an AudioWorklet to create a high-resolution timer, but very high sample rates are already allowed and have a similar risk so the marginal change in security is probably low.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

Low. The change is to ship a new API.

Reason this experiment is being extended

Unexpected delays in implementation, due in part to issues which were uncovered by the Origin Trial itself. We would like one more milestone for the trial.

Reason this experiment is being extended

During the last extension we resolved the fingerprinting concerns and landed what we thought were our final changes, but re-enabling tests that were added during early development revealed that some nodes still need to be manually updated. It's possible that the work could be finished before M152 branch, but it would be a very tight deadline so we would like one final extension to M153.

Reason this experiment is being extended

During the previous extension we uncovered additional fingerprinting concerns that we would like to resolve before shipping. Team member out of office time means that we will not be able to resolve this before M151, and we would like the trial extended to coincide with the new shipping date if possible to continue gathering feedback.

Ongoing technical constraints

None.

Debuggability

It may be worth exposing the render quantum size value in the DevTools WebAudio pane, similar to sample rate.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes
All supported platforms have mechanisms to implement this feature.

Is this feature fully tested by web-platform-tests?

Yes
https://wpt.fyi/results/webaudio/the-audio-api/the-audiocontext-interface/audiocontext-rendersizehint.html https://wpt.fyi/results/webaudio/the-audio-api/the-offlineaudiocontext-interface/offlineaudiocontext-rendersizehint.html

Flag name on about://flags

N/A (launch with --enable-features=WebAudioConfigurableRenderQuantum)

Finch feature name

WebAudioConfigurableRenderQuantum

Requires code in //chrome?

False

Tracking bug

https://crbug.com/40637820

Launch bug

https://launch.corp.google.com/launch/4416924

Measurement

UseCounters: WebAudioRenderSizeHint, WebAudioRenderQuantumSize

Availability expectation

We expect that Firefox will implement the feature independently at some point.

Adoption expectation

We expect that specific partners will use this functionality immediately upon its launch in Chrome.

Adoption plan

We are communication with partners, and also in communication with Mozilla via the Audio Working Group.

Non-OSS dependencies

Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function?

No.

Estimated milestones

Shipping on desktop	153
Origin trial desktop first	145
Origin trial desktop last	151
Origin trial extension 1 end milestone	151
Origin trial extension 2 end milestone	153
Origin trial extension 3 end milestone	152
DevTrial on desktop	145
Shipping on Android	153
Origin trial Android first	145
Origin trial Android last	151
Shipping on WebView	153
Origin trial WebView first	145
Origin trial WebView last	151

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

https://github.com/WebAudio/web-audio-api/issues/2663 https://github.com/WebAudio/web-audio-api/issues/2664

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5078190552907776?gate=5107396847468544

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/688d3254.2b0a0220.361edb.0299.GAE%40google.com
Intent to Experiment: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BuAeqS%3DygCo2wPaf0Cfo%2B%2BdEoHGWx%2Byc4%2BfO84U%2B_5hQqOvYg%40mail.gmail.com
Intent to Extend Experiment 1: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69dd7ab5.050a0220.c8e20.0171.GAE%40google.com
Intent to Extend Experiment 3: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6a3319c8.3af95f39.17d45c.005e.GAE%40google.com

This intent message was generated by Chrome Platform Status.

[Michael Wilson]

Hello all,

This is hopefully our final extension request for this feature.  As noted in the template, I am requesting for M153 in order to ensure we have time to do final updates that were discovered as necessary when re-enabling tests that were written during early development.  All anticipated large-scale changes have landed.

Best,

Michael

[Alex Russell]

Hey Michael,

LGTM for a 1 release extension on the condition that you also file an I2S and ship ASAP. We don't want OTs hanging out as "soft launch" mechanisms, and it sounds like you understand what bits of polish need to be added to make this widely usable. Under those conditions, we'd expect you to launch. Is that a mistaken read on the situation?

Best,

Alex

[Hongchan Choi]

Hi Alex,

That is correct. We discovered a few minor issues, primarily a couple of failing tests, while drafting the I2S. The team is already working on addressing these remaining items, and I plan to send out the I2S this week.

Thanks for the quick response!

Best,
Hongchan

[Michael Wilson]

On Wed, Jul 22, 2026 at 8:26 AM Alex Russell <sligh...@chromium.org> wrote:

We don't want OTs hanging out as "soft launch" mechanisms

I completely agree, and that's not our intention.  If for some reason we aren't able to launch in M153 we will let the trial expire.  We also want to launch as soon as possible.

it sounds like you understand what bits of polish need to be added to make this widely usable. Under those conditions, we'd expect you to launch. Is that a mistaken read on the situation?

I think that's our read on it too.  Optimistically it's possible that we can fix the remaining issues by Friday, but we had a discussion yesterday and ultimately decided it's better to delay the launch now.

Sorry about how development on this feature has been going.  There were some unexpected complexities and external circumstances that pushed the schedule out much further than we initially planned.

Best,

Michael