Min buffer size range detected on Android is huge (~1sec)

[kuviman]

While figuring out a mysterious audio delay on android when using web-audio-api crate - orottier/web-audio-api-rs#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.

[Rodrigodd]

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:

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.