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
<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
<https://github.com/WICG/web_audio_playout>
*Specification*
https://webaudio.github.io/web-audio-api/#AudioPlaybackStats
<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
<https://github.com/WICG/proposals/issues/142>
*TAG review*
Early TAG review request:
https://github.com/w3ctag/design-reviews/issues/939
<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
<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
<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
<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
<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
<https://g-issues.chromium.org/issues/475838360>
*Launch bug*
https://launch.corp.google.com/launch/4308993
<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
<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
<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
<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
<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
<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
<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>.
