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/40b28a8a-8ba3-494c-af8c-ca2d2f777090n%40chromium.org.
