Skip to content

Conversation

Hernqvist
Copy link

@Hernqvist Hernqvist commented Sep 16, 2025

Integrates the Playout Statistics API for WebAudio spec into the WebAudio spec.

The following changes are made between the version incubated in WICG and this PR:

  • "fallback"/"fallbackFrames" terminology is replaced with "underrun".
  • Duration types are changed from DOMHighResTimestamp to double.
  • Time units are changed from milliseconds to seconds.

Related issue: #2642


Preview | Diff

Copy link
Member

@hoch hoch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally looks good with some nits.

Also could you wrap the text at the column 80?

@Hernqvist
Copy link
Author

Implemented your comments and wrapped the lines at 80 (except where it would have cut through a link, which seems to be the standard for the rest of the document), thanks!

Copy link
Member

@hoch hoch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thanks!

@hoch hoch requested a review from padenot September 18, 2025 15:58
@hoch
Copy link
Member

hoch commented Sep 18, 2025

@padenot Could you take a look?

1. Set {{[[underrun duration]]}} to the total duration of all
[=underrun frames=] (in seconds) that
{{[[audio context]]}} has played since its construction.
1. Set {{[[underrun events]]}} to the number of times that {{[[audio context]]}}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm curious if this design holds up to distinguish these three cases

  1. occasional spike
  2. consistent overload -> consistent underruns (every quantum processed)
  3. periodic overload. as an example, a misaligned block based computation that ends up processing every N frames

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi!

  1. An occasional spike will manifest as a single increase in underrunDuration, and an increase in underrunEvents by 1.
  2. Consistent underruns will manifest as many small increases in underrunDuration, and many increases in underrunEvents.
  3. Similar to 1, but periodic. Since the API updates at most once per second (for privacy reasons), this might not be possible to immediately detect if N is small enough that we get several underruns per second. If N is large, it should be possible to see that the underruns occur at regular intervals. Also (if my math is correct) underrunEvents / currentTime should converge steadily towards sampleRate / N, so you could also look for that.

Co-authored-by: Christoph Guttandin <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants