Intent to Experiment: WebAudio: Configurable render quantum

[Michael Wilson]

Contact emails

hong...@chromium.org, mjwi...@chromium.org

Specification

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

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

https://github.com/w3ctag/design-reviews/issues/895

TAG review status

Issues addressed

Origin Trial documentation link

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

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.

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.

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	150
Origin trial desktop first	145
Origin trial desktop last	150
DevTrial on desktop	145
Shipping on Android	150
Origin trial Android first	145
Origin trial Android last	150
Shipping on WebView	150
Origin trial WebView first	145
Origin trial WebView last	150

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=5140327991869440

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

This intent message was generated by Chrome Platform Status.