LGTM for an extension to, inclusive, milestone 151.

/Daniel

On 2026-04-22 20:28, Michael Wilson wrote:
Hi Daniel,

    Is it correct that you are requesting a single milestone extension?

Yes, I'm requesting a single milestone extension to 151. Sorry that wasn't clear.

    can you tell us more about current feedback and why an extension
    beyond 150 is needed?

Feedback on the feature itself and its ergonomics has been positive.  However, the OT uncovered implementation issues we were not previously aware of, and time spent fixing them has pushed out my estimate of when we can ship. We would like the OT to be extended to coincide with the new shipping estimate.

Best,
Michael

On Wed, Apr 22, 2026 at 7:59 AM Daniel Bratell <[email protected]> wrote:

    Your current experiment is approved up to and including milestone
    150 (branching in a month or two). You mentioned 151 in your post.
    Is it correct that you are requesting a single milestone extension?

    If you do request that extension, or more, can you tell us more
    about current feedback and why an extension beyond 150 is needed?

    /Daniel

    On 2026-04-14 01:22, Chromestatus wrote:
    *Contact emails*
    [email protected], [email protected]

    *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*
    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
    
<https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EWebAudio%22>

    *Web Feature ID*
    web-audio <https://webstatus.dev/features/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.

    *Is this feature fully tested by web-platform-tests
    
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?*
    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.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


    This intent message was generated by Chrome Platform Status
    <https://chromestatus.com>.
-- You received this message because you are subscribed to the
    Google Groups "blink-dev" group.
    To unsubscribe from this group and stop receiving emails from it,
    send an email to [email protected].
    To view this discussion visit
    
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69dd7ab5.050a0220.c8e20.0171.GAE%40google.com
    
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69dd7ab5.050a0220.c8e20.0171.GAE%40google.com?utm_medium=email&utm_source=footer>.


--
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fd1d835a-e31a-40f4-a43b-dd518505b5f0%40gmail.com.

Reply via email to