Thanks Chris! Somehow Daniel's LGTM didn't show up in my Gmail thread. I can correctly see it in the Google Group thread <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGJqXNuW_e70x%2BoqF5iqu3XKUcxDa3d-ZZ-05TALwmu98ckXUg%40mail.gmail.com> .
Best, Hongchan On Wed, Feb 11, 2026 at 9:30 AM Chris Harrelson <[email protected]> wrote: > 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/CAGJqXNvuLWJXZznvh3ZA9oMQOQpnJeBDWMecP0jM_zHbKQ3-5A%40mail.gmail.com.
