jitterBufferTargetDelay

[henbos]

Fixes #19:

In the webrtc.org's implementation of the audio jitter buffer, the jitter buffer has an actual delay (jitterBufferDelay) and a target delay.

An implementation does not need to have a target, but for testing it is useful to be able to compare the actual value with the target value. This tells you something about how well samples get accelerated or decelerated.

Because this is a bit implementation-specific, and tells you more about the implementation's ability to deliver what it wants to deliver rather than direct measurements of achieved quality, this is added to the provisional stats spec for further evaluation.

---

Preview | Diff

---

Preview | Diff

[henbos]

Apparently this is already implemented and is exactly what ivoc@ was asking for but we forgot to merge the PR.

So I think we should at least merge this PR here (webrtc-provisional-stats) to reflect that it exists in C++ land, but can we go one step further and add it to the main spec (webrtc-stats)? @vr000m @alvestrand

[henbos]

We want to ship it to the web as well

[henbos]

This is https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/api/stats/rtcstats_objects.h;l=384;drc=6fb8d1a2d7c158caa1ddb63c9fa9b6a5e2548a43

[vr000m]

Just for my clarification, the target is not set by the app but by the internal stack and is response to network, cpu, other indicators.

[henbos]

Just for my clarification, the target is not set by the app but by the internal stack and is response to network, cpu, other indicators.

Yes it is the internal stack's target, which is not set by the app. The app can influence settings which may impact the target (A/V sync or playoutDelayHint) but is not in direct control of the target.

[henbos]

The overall target delay (this metric) could further be broken up into various other delays which if we want to know more about them should be exposed as other metrics, e.g. this issue was filed as a follow-up: https://github.com/w3c/webrtc-stats/issues/634