Contact emails
hong...@chromium.org,
mjwi...@chromium.org
Specification
https://webaudio.github.io/web-audio-api/#dom-baseaudiocontext-renderquantumsize
Design docs
No information providedhttps://github.com/WebAudio/web-audio-api/blob/main/explainer/user-selectable-render-size.md
Summary
AudioContext and OfflineAudioContext now take an optional renderSizeHint, which allows users to ask for a particular render quantum size when an integer is passed, to use the default of 128 frames if nothing or "default" is passed, or to ask the User-Agent to pick a good render quantum size if "hardware" is specified.
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/WebAudio/web-audio-api/pull/2469) A Firefox developer wrote the specification change.
WebKit: No signal
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.
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.
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 | 151 |
| Origin trial desktop first | 145 |
| Origin trial desktop last | 151 |
| Origin trial extension 1 end milestone | 151 |
| DevTrial on desktop | 145 |
| Shipping on Android | 151 |
| Origin trial Android first | 145 |
| Origin trial Android last | 151 |
| Shipping on WebView | 151 |
| 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=5366651127201792
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.comIntent 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