Hi Hongchan - there are 3 LGTMs in this thread: Alex, Mike and Daniel. So you're good to go, happy launching!
On Wed, Feb 11, 2026 at 8:57 AM 'Hongchan Choi' via blink-dev < [email protected]> wrote: > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGJqXNuW_e70x%2BoqF5iqu3XKUcxDa3d-ZZ-05TALwmu98ckXUg%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/CAOMQ%2Bw93TZF7m5WNuJf1eENmJqYMdoqdLG%3DnLToL%3DLPa8aKniQ%40mail.gmail.com.
