cpal icon indicating copy to clipboard operation
cpal copied to clipboard

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

Open kuviman opened this issue 1 year ago • 1 comments

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.

kuviman avatar Jun 12 '24 19:06 kuviman

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.

Rodrigodd avatar Jun 13 '24 14:06 Rodrigodd