Stat for audio acceleration/expand rate?

[henbos]

The non-standardized Chromium getStats contains the following stat:

// Fraction of audio samples accelerated (removed) when the jitter buffer size decreases.
ssrc.googAccelerateRate

Is this useful? Should this be standardized as double accelerationRate in RTCMediaStreamTrackStats?

When it decreases? During what time frame does this rate apply?

[alvestrand]

Commentary:

1. this is a rate, which comes under the general ban on rate-valued stats.
2. I'd perhaps go with "samplesInsertedByRateAdaption" (too long winded?), which may be positive or negative. Rate can be computed from that; we shouldn't need a sample counter to divide by, since that's derivable from time + sample rate.

[henbos]

@alvestrand WRT "we shouldn't need a sample counter to divide by, since that's derivable from time + sample rate", what sample rate? There are constraints but no stat for that. Packets != samples. And actual sample rate might vary and not be current rate * time.

WRT samplesInsertedByRateAdaption being both positive or negative I don't think it flies to have a single counter, samples can both be removed (googAccelerateRate) or added (googPreemptiveExpandRate) over a period of time but the sum could be zero.

Adding @hlundin. How about?

RTCMediaStreamTrackStats.samplesInserted
RTCMediaStreamTrackStats.samplesRemoved
The number of samples that have been inserted/removed in order to slow down/speed up audio as the jitter buffer increases/decreases.

RTCMediaStreamTrackStats.sampleCount
The number of samples that have been added to the jitter buffer. This count includes both samples that have been inserted (samplesInserted) and samples that have been removed (samplesRemoved).

Or is "rate adaption" preferred over "jitter buffer"?

So googAccelerateRate ~= samplesRemoved / sampleCount and googPreemptiveExpandRate ~= samplesInserted / sampleCount if samples were to be counted over the same time period as the goog-rates.

[vr000m]

Following up on the discussion:

What is it that we are trying to measure here:

• Size of the current or average jitter buffer?

• Did the jitter buffer increase or decrease? by how much?

• How many samples/packets added and removed from the jitter buffer?

I have a feeling that with the samplesInserted, we'd have more samples than they were generated by the sender?

[vr000m]

And another question about inserting and removing sample, when does this happen or under what conditions does it happen?

For example,

• to bring audio and video in to sync?
• when the jitterbuffer is going to underflow or overflow? I am assuming the overflow can only happen in the case of a fixed size jitter buffer or at the moment in time it cannot be expanded?
• or when a low or high watermark in the jitter buffer is met, i.e., the application realises that it needs to slow down or speed up the processing, otherwise this will cause perceptible audio quality issues.

[vr000m]

moving the comment to #152

[henbos]

Based on offline discussions, information about jitter buffer increase and decreasing should be covered by measurements of the delay of various buffers, see #151. Closing this one.