Thanks all for the review and approvals. One quick question: it looks like the Chrome Status I2S gate is now green with 3 LGTMs, but I don't see the 3rd LGTM in this thread. Can you advise? https://chromestatus.com/feature/5172818344148992?gate=5078819495215104
Best, Hongchan On Wed, Feb 11, 2026 at 8:04 AM Mike Taylor <[email protected]> wrote: > LGTM2 > On 2/10/26 6:02 p.m., 'Hongchan Choi' via blink-dev wrote: > > Thank you for the review and approval, Alex! > > Best, > Hongchan > > > > On Tue, Feb 10, 2026 at 1:49 PM Alex Russell <[email protected]> > wrote: > >> Hey Hongchan, >> >> This is helpful and explains why it should be different. LGTM1, and >> thanks for your patience. >> >> Best, >> >> Alex >> >> On Monday, February 9, 2026 at 11:50:28 AM UTC-8 Hongchan Choi wrote: >> >>> Hello Alex, >>> >>> Perhaps my explanation on different paradigms between <audio> >>> (HTMLMediaElement) and Web Audio was not effective: >>> >>> 1. Pull Model: WebAudio uses a pull model. The system's audio callback >>> demands a buffer of data at a precise interval. If the application fails to >>> provide it in time, you get an underrun (a literal gap in the output >>> stream). This is a real-time performance failure. >>> 2. Push Model: The <audio> element follows a push model (streaming). >>> When data is missing, the element enters a waiting state, pauses playback, >>> and fires a waiting event >>> <https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement/waiting_event>. >>> This is considered 'buffering,' which is an expected behavior of >>> network-based streaming, not necessarily a failure of the audio engine >>> itself. >>> 3. Existing events: We already have ways to monitor <audio> stalls via >>> the waiting, stalled >>> <https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement/stalled_event>, >>> and playing events to signal the streaming/networking problems. >>> >>> The another important distinction is the developer's ability to respond >>> to it: >>> >>> 1. For WebAudio, an underrun is typically a CPU/scheduling issue where >>> the audio thread cannot keep up with the graph load/complexity. For the >>> <audio> element, 'stalled/watiing' status are mostly network-related. >>> 2. This API is very useful for WebAudio apps because it provides the >>> signal needed for load balancing. If a developer sees underruns increasing, >>> they can dynamically simplify their DSP graph, reduce voices, or bypass >>> expensive effects to restore real-time stability. >>> 3. In contrast, for the <audio> element, the browser automatically >>> handles the 'lack of audio frames' by pausing and entering a waiting state. >>> There is no 'internal logic' for the developer to adjust other than waiting >>> for the network data to arrive. >>> >>> Hopefully this answer your question! >>> >>> Best, >>> Hongchan >>> >>> On Monday, February 9, 2026 at 11:15:57 AM UTC-8 Alex Russell wrote: >>> >>>> I'm a little confused about why we think playback contexts like <audio> >>>> don't have similar issues when streaming. E.g., I understand that <audio> >>>> can point at a source which isn't fully loaded, which will lead to >>>> underruns and skipping during playback. Shouldn't we cover that case with a >>>> uniform API? >>>> >>>> Best, >>>> >>>> Alex >>>> >>>> On Wednesday, February 4, 2026 at 10:22:39 AM UTC-8 Hongchan Choi wrote: >>>> >>> Thanks for your response, Yoav. >>>>> >>>>> > Can you elaborate a bit more on any risks, if any? >>>>> >>>>> - fhernqvist@ published this detailed self-review >>>>> <https://docs.google.com/document/d/1wGv_mr7Lgg2w-6PuKDrcScoa8IvYAOW3PMTFW85O3Gw/edit?tab=t.0> >>>>> in 2024. >>>>> - There was also a discussion about the covert channeling >>>>> <https://github.com/WICG/audio-context-playout-stats?tab=readme-ov-file#cross-site-covert-channeling>, >>>>> but the mitigation was designed/implemented after the privacy/security >>>>> team's approval. >>>>> >>>>> > Can you file for signals for both Gecko and WebKit? >>>>> https://www.chromium.org/blink/launching-features/wide-review/#standards-positions >>>>> >>>>> Done: >>>>> Gekco: https://github.com/mozilla/standards-positions/issues/1351 >>>>> WebKit: https://github.com/WebKit/standards-positions/issues/610 >>>>> >>>>> > Any feedback from the OT? >>>>> >>>>> The current partner mentioned that "The metrics collected from are >>>>> continuously used for the experimentation, we would not be able to verify >>>>> the quality without them." >>>>> >>>>> Hopefully this answers your question! >>>>> >>>>> Best, >>>>> Hongchan >>>>> >>>>> >>>>> >>>>> On Tue, Feb 3, 2026 at 8:25 PM Yoav Weiss (@Shopify) < >>>>> [email protected]> wrote: >>>>> >>>> On Monday, February 2, 2026 at 9:38:43 PM UTC+1 Hongchan Choi wrote: >>>>>> >>>>> Thanks for reviewing the intent, Alex. >>>>>> >>>>>> Regarding unified behavior with RTCAudioSourceStats, I don't believe >>>>>> this API serves the same goal. WebAudio’s stats are centered specifically >>>>>> around audio stream quality, so I am unsure about achieving unified >>>>>> behavior across these different APIs. >>>>>> >>>>>> As for getting similar stats from the <audio> element or WebRTC >>>>>> contexts, both HTMLAudioElement and WebRTC's audio systems are >>>>>> "push-based." By design, they should not experience audio sample dropouts >>>>>> or glitches in the same way. The WebAudio (pull-based) playback stats are >>>>>> specifically designed to catch dropouts so developers can estimate the >>>>>> user's audio quality and experience. >>>>>> >>>>>> Hopefully this answers your question! >>>>>> >>>>>> Best, >>>>>> Hongchan >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Feb 2, 2026 at 12:14 PM Alex Russell <[email protected]> >>>>>> wrote: >>>>>> >>>>>> Hey Hongchan, >>>>>> >>>>>> This looks extremely useful! >>>>>> >>>>>> I'm a little surprised to see that the TAG didn't ask about alignment >>>>>> with other APIs in the space, e.g.: >>>>>> >>>>>> https://developer.mozilla.org/en-US/docs/Web/API/ >>>>>> RTCAudioSourceStats >>>>>> >>>>>> Will we get unified behaviour here? Will it be possible to get >>>>>> similar stats from an <audio> element or WebRTC contexts, e.g.? >>>>>> >>>>>> Best, >>>>>> >>>>>> Alex >>>>>> >>>>>> On Friday, January 30, 2026 at 7:27:33 AM UTC-8 Chromestatus wrote: >>>>>> >>>>>> *Contact emails* >>>>>> [email protected], [email protected], [email protected] >>>>>> >>>>>> >>>>>> >>>>>> *Explainer* >>>>>> https://github.com/WICG/web_audio_playout >>>>>> >>>>>> *Specification* >>>>>> https://webaudio.github.io/web-audio-api/#AudioPlaybackStats >>>>>> >>>>>> *Summary* >>>>>> This feature adds an AudioContext.playbackStats attribute which >>>>>> returns an AudioPlaybackStats object. This object provides audio playback >>>>>> statistics such as average latency, minimum/maximum latency, underrun >>>>>> duration, and underrun count. This API allows web applications to monitor >>>>>> audio playout quality and detect glitches. Note: This feature was >>>>>> previously tracked as AudioContext.playoutStats. It has been renamed to >>>>>> AudioContext.playbackStats to align with the final Web Audio API >>>>>> specification. The old name is supported as a deprecated alias for >>>>>> backward >>>>>> compatibility. >>>>>> >>>>>> *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> >>>>>> >>>>>> *Motivation* >>>>>> There is currently no way to detect whether WebAudio playout has >>>>>> glitches (gaps in the played audio, which typically happens due to >>>>>> underperformance in the audio pipeline). There is an existing way to >>>>>> measure the instantaneous playout latency using >>>>>> AudioContext.outputLatency, >>>>>> but no simple way to measure average/minimum/maximum latency over time. >>>>>> With this API, we want to propose a way to be able to measure the delay >>>>>> of >>>>>> that audio and the glitchiness of the audio. >>>>>> >>>>>> *Initial public proposal* >>>>>> https://github.com/WICG/proposals/issues/142 >>>>>> >>>>>> *TAG review* >>>>>> Early TAG review request: https://github.com/w3ctag/ >>>>>> design-reviews/issues/939 >>>>>> >>>>>> *TAG review status* >>>>>> Issues addressed >>>>>> >>>>>> *Origin Trial Name* >>>>>> Playout Statistics API for WebAudio >>>>>> >>>>>> *Chromium Trial Name* >>>>>> AudioContextPlayoutStats >>>>>> >>>>>> *Origin Trial documentation link* >>>>>> https://github.com/WICG/web_audio_playout >>>>>> >>>>>> *WebFeature UseCounter name* >>>>>> kAudioContextPlayoutStats >>>>>> >>>>>> *Risks* >>>>>> >>>>>> >>>>>> *Interoperability and Compatibility* >>>>>> *No information provided* >>>>>> >>>>>> Can you elaborate a bit more on any risks, if any? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *Gecko*: Positive (https://github.com/WebAudio/web-audio-api/pull/ >>>>>> 2645) The spec PR was reviewed and approved by a Mozilla engineer. >>>>>> >>>>>> *WebKit*: No signal >>>>>> >>>>>> >>>>>> Can you file for signals for both Gecko and WebKit? >>>>>> https://www.chromium.org/blink/launching-features/wide-review/#standards-positions >>>>>> >>>>>> >>>>>> >>>>>> *Web developers*: Positive (https://github.com/ >>>>>> WICG/proposals/issues/142#issuecomment-1981012486) >>>>>> >>>>>> *Other signals*: >>>>>> >>>>>> *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? >>>>>> None. >>>>>> >>>>>> >>>>>> *Debuggability* >>>>>> Can be tested by creating an AudioContext and evaluating >>>>>> context.playoutStats in the console. >>>>>> >>>>>> *Will this feature be supported on all six Blink platforms (Windows, >>>>>> Mac, Linux, ChromeOS, Android, and Android WebView)?* >>>>>> Yes >>>>>> >>>>>> *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-playoutstats. >>>>>> html?label=experimental&label=master&aligned These will be updated >>>>>> if the API shape changes. >>>>>> >>>>>> *Flag name on about://flags* >>>>>> *No information provided* >>>>>> >>>>>> *Finch feature name* >>>>>> AudioContextPlayoutStats >>>>>> >>>>>> *Rollout plan* >>>>>> Will ship enabled for all users >>>>>> >>>>>> *Requires code in //chrome?* >>>>>> False >>>>>> >>>>>> *Tracking bug* >>>>>> https://g-issues.chromium.org/issues/475838360 >>>>>> >>>>>> *Launch bug* >>>>>> https://launch.corp.google.com/launch/4308993 >>>>>> >>>>>> *Availability expectation* >>>>>> Feature is available only in Chromium browsers for the foreseeable >>>>>> future. >>>>>> >>>>>> *Adoption expectation* >>>>>> Feature is used by specific partner(s) to provide functionality >>>>>> within 12 months of launch in Chrome. >>>>>> >>>>>> *Adoption plan* >>>>>> Nothing specific planned. >>>>>> >>>>>> *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? >>>>>> None. >>>>>> >>>>>> *Estimated milestones* >>>>>> Shipping on desktop146 Origin trial desktop first131 Origin trial >>>>>> desktop last136 Origin trial extension 1 end milestone145 Origin >>>>>> trial extension 2 end milestone142 Origin trial extension 3 end >>>>>> milestone139 DevTrial on desktop129 Shipping on Android146 Shipping >>>>>> on WebView146 >>>>>> >>>>>> >>>>>> Any feedback from the OT? >>>>>> >>>>>> >>>>>> >>>>>> *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). >>>>>> None. >>>>>> >>>>>> *Link to entry on the Chrome Platform Status* >>>>>> https://chromestatus.com/feature/5172818344148992?gate= >>>>>> 5078819495215104 >>>>>> >>>>>> *Links to previous Intent discussions* >>>>>> Intent to Prototype: https://groups.google.com/a/ >>>>>> chromium.org/d/msgid/blink-dev/CACazmWW4MYVa_iGjN%3DK4O9B1DE3rt4_ >>>>>> 2Vkqnq6sKswHFjn6BzQ%40mail.gmail.com >>>>>> Intent to Experiment: https://groups.google.com/a/ >>>>>> chromium.org/d/msgid/blink-dev/CACazmWWV6S6Ba%3Dd% >>>>>> 3DgvjhERm1OnPyBMRJx5fbkP%3Df9zb3k%3DrNDA%40mail.gmail.com >>>>>> Intent to Extend Experiment 1: https://groups.google.com/a/ >>>>>> chromium.org/d/msgid/blink-dev/691455eb.2b0a0220.e30ce. >>>>>> 7e1f.GAE%40google.com >>>>>> Intent to Extend Experiment 2: https://groups.google.com/a/ >>>>>> chromium.org/d/msgid/blink-dev/686d135c.2b0a0220.3a1521. >>>>>> 0081.GAE%40google.com >>>>>> Intent to Extend Experiment 3: https://groups.google.com/a/ >>>>>> chromium.org/d/msgid/blink-dev/CACazmWVkWb8DJM_aCRGOFpskBs-7h%3DO_ >>>>>> yggKc3YBUkiieEO-UA%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/CAGJqXNs6LMOXKSrQAq6qX3hmrC6ojvkQDHH8QJ336ZUm31gBDw%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGJqXNs6LMOXKSrQAq6qX3hmrC6ojvkQDHH8QJ336ZUm31gBDw%40mail.gmail.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/CAGJqXNuW_e70x%2BoqF5iqu3XKUcxDa3d-ZZ-05TALwmu98ckXUg%40mail.gmail.com.
