Add AudioPlayoutStats interface

[Hernqvist]

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

[hoch]

Generally looks good with some nits.

Also could you wrap the text at the column 80?

[Hernqvist]

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!

[hoch]

LGTM. Thanks!

[hoch]

@padenot Could you take a look?

[ulfhammarqvist-st]

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

[Hernqvist]

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.

[padenot]

Some comments.

[padenot]

Suggested change

	Audio underruns (also commonly called glitches) are gaps in the audio
	playout which occur when the audio pipeline cannot deliver audio on time.
	Underruns (often manifesting as audible "clicks" in the playout) are bad
	for the user experience, so if any of these occur it
	can be useful for the application to be able to detect them and possibly
	take some action to improve the playout.
	Audio underruns (also commonly called glitches) are gaps in the audio
	playback that occur when an audio pipeline cannot deliver audio on time.
	Underruns (often manifesting as audible "clicks" in the playout) are bad
	for the user experience, so if any of these occur it
	can be useful for the application to be able to detect them and possibly
	take some action to improve the playout.

we probably need to rephrase this. When the audio isn't delievered on time, it causes an audio underrun, that causes a discontinuity, that causes and audible click, that can be called a glitch. This is because of the synchronous nature of the AudioContext, unlike for example a PeerConnection, that will do something when audio input is missing to cover it up.

[Hernqvist]

I rephrased, how about now?

[padenot]

Yes, but only if:

• There is a linearization point somewhere on the system (typically the audio mixer, be it in the OS or in the browser)
• The callbacks are effectively synchronous all the way from this linearization point, without a buffer in between that could flatten load spikes (that could be because of a different AudioContextLatencyCategory).

[Hernqvist]

I agree, the side channel is likely only possible/efficient on a subset of systems, but should we mention this in the spec?

[padenot]

I'd like to have a sentence or two about this yes, to convey a nuanced level of importance.

[Hernqvist]

Thanks for the review!

[Hernqvist]

I rephrased, how about now?