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>.
