calculateLatencyMillis() again

[extreamsd]

In reference to crashes while calling calculateLatencyMillis() from within onAudioReady():

#1489
#1499

and the recommendation to "NOT calling getTimestamp or calculateLatencyMillis() from a callback", I started doing some measurements.

When calling calculateLatencyMillis() from within onAudioReady() (Android 12, Samsung S10e, but this goes for many devices) and log the values, I get output like:
lat 19.906731 3.240693
lat 19.711769 4.073384
lat 19.963461 3.776384
lat 19.919269 3.790769
lat 19.953769 3.775154
lat 18.666308 3.801077
lat 18.780154 3.771346
lat 18.866424 3.760307
lat 18.839462 3.745115
lat 18.886616 3.742961
lat 18.701462 3.800846
lat 18.096270 4.245346
lat 18.715539 3.789692
lat 18.815847 3.768577
lat 18.768539 3.792308

Left value is playback latency, right value is recording latency.

If I then call calculateLatencyMillis() from the UI thread just before flipping an atomic switch to 'stop' the recording (which is not really stopping the stream, but just not doing anything in the callback when set), I get:

lat 18.923231 0.000000

and right after the UI thread has waited for the callback to be called once with the 'stopped' value, I get:

lat 24.192347 6.529962

The latency values logged from within the callback are never above 19 (play) and never above 4 (rec). So, following the recommendation not to call calculateLatencyMillis() from the callback results in values that are not representative for the actual situation it seems. Bug/limitation or am I doing something wrong?

[philburk]

It does not surprise me that you get different latency values at different times.
Latency also varies depending on how you calculate it. And when you query the frame counts.
Also the timestamps have some jitter from the HAL measurements.
The timestamps can also have a constant bias from inaccurate estimates of the buffer sizes and depth in the buffers close to the hardware. If you are using Bluetooth then the inaccuracy can be quite high.

Actual latency is constantly changing in a sawtooth pattern.

For output the latency is at a minimum at the beginning of the callback.
Then it increases linearly with time until the next callback.

For input the sawtooth is at a maximum at the beginning of the callback.
Then it decreases linearly with time until the next callback.

So if you sample these latencies asynchronously they will normally fluctuate.

For a full duplex stream the sum of the output and input latencies should be constant.