On Wed, Jul 22, 2026 at 8:26 AM Alex Russell <[email protected]> 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 On Wed, Jul 22, 2026 at 8:53 AM Hongchan Choi <[email protected]> wrote: > 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 > > > > On Wed, Jul 22, 2026 at 8:26 AM Alex Russell <[email protected]> > wrote: > >> 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 >> >> On Tuesday, July 21, 2026 at 2:46:43 PM UTC-7 Michael Wilson wrote: >> >>> 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 >>> >>> On Tue, Jul 21, 2026 at 2:43 PM Chromestatus < >>> [email protected]> 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* >>>> 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 >>>> <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/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 >>>> <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 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 >>>> <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/CA%2BuAeqTO4hR6g967MBxap9t0TGrt8pcy6J-b1t2Y%2BpJGuZNvKQ%40mail.gmail.com.
