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/e118766f-4de2-41d2-b685-4fdcd1244acbn%40chromium.org.
