Repository navigation
Adjust OpenSL ES buffer queue length based on capacity #744
Description
Change kBufferQueueLength constant to mBufferQueueLength variable.
Set mBufferQueueLength based on capacity and callbacksize.
See experiment on the effect of kBufferQueueLength on latency in:
Why Oboe only enqueue one buffer? #464
Understanding FramesPerCallback / kBufferQueueLength / Buffer Size #736
According to this internal bug:
b/27819623 | Allow OpenSL ES to specify a total buffer size for a fast track
starting in N, adding more buffers would improve glitch protection. So this change would help devices running 7.0, 7.1 and 8.0. That would be about 1/3 of Android devices. For 8.1 and later, AAudio is available.
[Update: as of August 2022, 17.5% of devices are running < 8.1]
Reacted by Seth Sandler
Activity
klw111 commented on Mar 24, 2020
Allow OpenSL ES to specify a total buffer size for a fast track
Has this feature implemented in branch 1.3-stable？
philburk commented on Mar 29, 2020
No. This issue is still open.
philburk commented on Aug 6, 2022
Measure the effect of changing kBufferQueueLength on Sargo running SP2A with OpenSL ES with Low Latency.
Burst = 192.
Latency increases by 2 msec (96 frames) per buffer. Not 192!
Used main Oboetester screen to set frames per callback to 96.
The latency still increases by 2 msec/buffer but the latency is lower!
I then set kBufferQueueLength and added some code to the beginning of processBufferCallback(). Burst = 192.
if (getBufferDepth(bq) >= 3) {
return false;
}
This does not seem to affect latency! I expected it to limit the amount of data in the buffer.
I added some logs and the depth was always zero.
philburk commented on Aug 6, 2022
I then added a loop in processBufferCallback:
while (depth < 4 && countdown-- > 0 && !shouldStopStream) {In the first callback I could see the depth grow to four then stabilize.
At 9 it failed to start because there were only 8 buffers allocated.
philburk commented on Aug 6, 2022
Hypothesis: in Android S the kBufferQueueLength affects the size of the internal buffer, which increases latency and should afford some glitch protection. Enqueuing multiple buffers increases the queue depth, adds latency. But I suspect these buffers are stored on the client side and will not help with glitch protection.
opensles: implement capacity using buffer queue length
philburk commented on Aug 8, 2022
Testing on a Nexus 6 running SDK 6.0.1, burst = 192.
Use format = PCM_I16 for input and output, analog headset jack.
Latency, and glitch protection, does not increase with the number of buffers. That was added in 7.0. ag/941250
SDK 6.0 has problems that we cannot fix in Oboe.
philburk commented on Aug 8, 2022
Testing on a Nexus 6 running SDK 7 MR2, burst = 192.
Use format = PCM_I16 for input and output, analog headset jack.
Latency, and glitch protection, increases with the number of buffers.
opensles: implement capacity using buffer queue length (#1601)