FP2-1887: bluetooth: a2dp: Property account pcm.counter
bluetooth: a2dp: Property account pcm.counter
Every tick we account that there is now pcm_bytes_per_tick *
number_of_ticks (since last accounting).
The existing code would be right with infinite precision floating
point math but with integer math undercounts the amount of PCM
data that is available.
For example, if we have 20ms ticks and we have two ticks that occur
at intervals of 20543 us and 39457 us (a total of 3 ticks) and we
generate 3528 bytes of PCM data per tick (44100 * 2 channels * 16bit)
then we should determine that there is exactly 10584 new bytes of
PCM data available. It actually computes that there are
3528 * 20543 / 20000 = 3623.7852 vs. int 3623 bytes +
3528 * 39457 / 20000 = 6960.2148 vs. int 6960
--------- -----
10584 vs. 10583
Similarly for 48K audio which generated 3840 bytes per frame
3840 * 20543 / 20000 = 3944.2560 vs. int 3944 bytes +
3840 * 39457 / 20000 = 7575.7440 vs. int 7575 bytes
--------- -----
11520 vs. 11519
Which means that on average we are undercounting about half a byte
per actual tick that occurs.
In practice if you assume 25ms per tick when we are asking for
20ms then we are losing 1 byte of data about every 50ms, 20
bytes per second or 1200 bytes per minute. 1200 bytes is about
7ms of audio is lost every minute.
Change-Id: I413d764adcf0210a995aebde91908e3ed1d3b00d
1 file changed