Min buffer size range detected on Android is huge (~1sec)
While figuring out a mysterious audio delay on android when using web-audio-api crate - https://github.com/orottier/web-audio-api-rs/issues/515
I found that cpal reports a huge min buffer size (when using Device::default_output_config)
It looks like the min buffer size is calculated using java api AudioTrack.getMinBufferSize
Trying using that API directly in a sample Kotlin app like this:
val size = AudioTrack.getMinBufferSize(44100, AudioFormat.CHANNEL_OUT_STEREO, AudioFormat.ENCODING_PCM_FLOAT);
reports the same huge buffer size (~40000, a bit random every time).
Tested on Google Pixel 7 Pro
Since web-audio-api was clamping buffer size to the reported range I got a ~1 sec delay.
On one hand the issue is not in cpal itself, but whatever the reason is for this huge min buffer size.
On the other hand, I thought that maybe using java apis here doesnt make much sense since the actually used audio api is oboe the c++ library.
I'm not sure what to do with any of that but thought you guys might know about my findings here.
In web-audio-api the solution was to just use Default buffer size without trying to calculate it based on reported ranges.
I also have stumble on the same problem a while ago, and I fixed it by hardcoding the performance mode of the AudioStream as LowLatency, in my cpal fork:
https://github.com/RustAudio/cpal/compare/master...Rodrigodd:cpal:oboe-low-latency
At the time I was not sure if it was correct to just hardcode it there, or if it was better to expose it in the cpal API (which would be a lot more work), so I didn't attempt to upstream this change.