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/251331fb-efb6-45e2-86f7-c6393bc66d2cn%40chromium.org.
