Add MediaStreamTrackAudioStats interface

[henbos]

Only partially fixes #96, but is missing latency

The RTCAudioSourceStats contains capture related metrics that are better suited for a MediaStreamTrack method than RTCPeerConnection.getStats() since you may be capturing for a non-WebRTC context. Moving the metrics was covered by the April 18, 2023 Virtual Interim and the Working Group input was supportive of the move.

Since then I've updated the language to talk about audio frames rather than audio samples and to use the same language about "delivered" vs "dropped" that we used in the video stats case.

This is the new interface (edited to match latest patch set):

[Exposed=Window]
interface MediaStreamTrackAudioStats {
  readonly attribute unsigned long long deliveredFrames;
  readonly attribute DOMHighResTimeStamp deliveredFramesDuration;
  // TODO: Moved to #119
  // readonly attribute DOMHighResTimeStamp deliveredFramesLatency;

  readonly attribute unsigned long long totalFrames;
  readonly attribute DOMHighResTimeStamp totalFramesDuration;

  [Default] object toJSON();
};

Edit: From the October interim minutes, conclusion: "Overall approach makes sense, flesh out the details in the editors meeting"

---

Preview | Diff

[henbos]

History: Already covered in the April Virtual Interim and a PR like this "kind-of" already got approved in #97, but then that started the whole async vs sync debate so we never merged that

[henbos]

Thought: In order to be consistent with video stats, where we don't have droppedFrames - instead we have totalFrames, we should consider changing this PR to have totalFrames and totalFramesDuration instead of "dropped".

The app could simply calculate "droppedFramesDuration" as totalFramesDuration - deliveredFramesDuration.

So the glitch% would be (totalFramesDuration - deliveredFramesDuration) / totalFramesDuration

[henbos]

Based on the Virtual Interim, I should:

• Replace droppedFrames with totalFrames (dropped = total - delivered so the same information is exposed it's just a different format). The reason for this is to make the audio stats consistent with video stats, which has totalFrames instead of droppedFrames already.
• Rename "delay" to "latency".
• Some clarifications if necessary, e.g. make sure everyone is on the same page on what delivered means and spell out the fact that latency and deliveredFrames need to increment simultaneously.

[henbos]

PR updated!

[henbos]

There's a section in the webrtc stats spec (here) that motivates total counters versus instantaneous values or pre-computed averages. Part of the API shape discussions that the WG has had was to do totals in track.stats as well for the same reasons.

[henbos]

Spoke with Jan-Ivar, I think it makes sense to also have the latest latency sample for use cases like A/V sync, in addition to average latency over app defined interval

[henbos]

I also filed https://github.com/w3c/mediacapture-extensions/issues/119 to add latency of the latest audio frame for use of A/V sync. The avg latency is still useful for "what was the quality during interval X"

[jan-ivar]

@padenot does #119 satisfy your concern about obtaining the most current value?

[henbos]

I added the current latency in follow up PR #120 but because I can't figure out how to create PR chains, this PR needs to land first so I can rebase the next PR. In the meantime its diff contains both PRs

[henbos]

Friendly ping

[jan-ivar]

The editors can integrate label is so @henbos can merge this after @padenot looks at it tomorrow.

[henbos]

Unless anyone objects, I will merge this on Monday.