fix(aaudio): Correctly detect minimum buffer size #1039

will3942 · 2025-10-27T11:40:02Z

AAudio buffer size minimum should be detected using the PROPERTY_OUTPUT_FRAMES_PER_BUFFER on the AudioManager not using AudioTrack.

Android documentation reference: https://developer.android.com/ndk/guides/audio/audio-latency#buffer-size

This allows for a sensible buffer size minimum to be used in comparison to the 1 second+ buffer sizes reported by AudioTrack.

Tested on a Samsung Galaxy Tab A9: SupportedStreamConfigRange { channels: 1, min_sample_rate: SampleRate(5512), max_sample_rate: SampleRate(5512), buffer_size: Range { min: 256, max: 2147483647 }, sample_format: I16 }

Closes: #890

…UT_FRAMES_PER_BUFFER on the AudioManager not using AudioTrack

roderickvd

Thanks for the contribution!

src/host/aaudio/mod.rs

src/host/aaudio/java_interface/audio_manager.rs

src/host/aaudio/mod.rs

will3942 · 2025-10-28T20:33:52Z

Thanks for the contribution!

Thanks for the review - will address all feedback in the morning. The Q around input is an interesting one, I couldn't see anything different for input in their docs but also I agree the property is named after output so...

will3942 · 2025-10-29T13:07:07Z

This works well now - longer term I think we should look at a few feature requests:

Allow querying the configuration that the stream is using - e.g. if you use BufferSize::Default, you can see the buffer size the underlying host has used. AAudio supports this, I'm sure others do too.
Edit the stream configuration (where supported) after construction - AAudio supports/recommends this for buffer size tuning
Bringing back Oboe support - Oboe does some magic around buffer size / latency setting that we could leverage. The Android docs for ndk/aaudio recommend this.

This is a squashed version of RustAudio#1039, 2b19dd8

roderickvd

Thanks for addressing the earlier comments. Here's a couple of what should be the last nits.

roderickvd · 2025-11-12T02:05:51Z

src/host/aaudio/java_interface/audio_manager.rs

+
+    frames_per_buffer_string
+        .parse::<i32>()
+        .map_err(|e| jni::errors::Error::JniCall(jni::errors::JniError::Unknown))


Would it make sense to retain the error message and return something like jni::errors::Error::ParseError(format!("Failed to parse frames per buffer: {}", e))?

I've fixed this, the master version of jni is nicer, to do this with the current supported version I have had to add combine as a dependency which I don't love. Let me know what you think? I can't see a great solution here for passing the error back through.

Agreed, if we can prevent pulling in another dependency then let's put in that effort. How about JniCall(JniError::Other(String))?

JniError::Other(jint) is the signature so it won't accept a string.

We only really have ParseFailed with the additional dependency or FieldAlreadySet(String)

@roderickvd The crate jni will get released at some point which will allow us to use ParseFailed(String) without an external dependency. In the meantime I think we have three choices:

Pull in combine dependency and use ParseFailed

Use FieldAlreadySet(String)

Add a TODO to update to ParseFailed(String) on jni release and just return the error without the string.

I'm leaning towards 3 or 2 (also with a TODO).

What's your preference? I can then implement this - I'd love to get this across the line with the next release so we don't have to run a patch for cpal.

I've updated this and gone with 3 - this feels the best in my mind, let me know if you want me to change.

Makes sense. Let's not spend too much time over it. If you'd want to track it and deal with it later?

src/host/aaudio/android_media.rs

roderickvd · 2025-11-12T02:13:29Z

This works well now - longer term I think we should look at a few feature requests:

Allow querying the configuration that the stream is using - e.g. if you use BufferSize::Default, you can see the buffer size the underlying host has used. AAudio supports this, I'm sure others do too.

Yes. #964 also added querying latency - we could go from there.

Edit the stream configuration (where supported) after construction - AAudio supports/recommends this for buffer size tuning

That's interesting for mobile platforms. I believe iOS does too?
Question is how this could work elegantly in cpal.

Bringing back Oboe support - Oboe does some magic around buffer size / latency setting that we could leverage. The Android docs for ndk/aaudio recommend this.

You know why Oboe was removed in the first place? (I don't.)

will3942 · 2025-11-12T11:56:31Z

Yes. #964 also added querying latency - we could go from there.

Agreed. Documeted as an issue / feature request - #1042

That's interesting for mobile platforms. I believe iOS does too? Question is how this could work elegantly in cpal.

This could work as functions on the Stream trait? Although I'm not sure if this is universally supported functionality across platforms.

You know why Oboe was removed in the first place? (I don't.)

Pros/cons where detailed here - #961

will3942 · 2025-11-12T11:58:20Z

@roderickvd addressed the nits - let me know your feedback on the last one.

roderickvd · 2025-11-13T00:06:25Z

That's interesting for mobile platforms. I believe iOS does too? Question is how this could work elegantly in cpal.

This could work as functions on the Stream trait? Although I'm not sure if this is universally supported functionality across platforms.

We'd have to map out the API and judge how it'd impact the various hosts. Preferably, it'd keep things simple.

The ALSA host would also be a candidate, because we can play the same game: requesting a large buffer with X periods but only using the first Y periods of it, and dynamically tuning Y. But, to the point of keeping things simple, we'd have to play around to see how easy it is to do that in the poll cycle.

You know why Oboe was removed in the first place? (I don't.)

Pros/cons where detailed here - #961

Ah, thanks, could've looked for that myself 😊 That makes it seem like there's almost no cons and all pros, yet you refer to something that Oboe does by itself and NDK doesn't? If we can implement dynamic buffers without the weight of Oboe, that'd also be nice, no?

@roderickvd addressed the nits - let me know your feedback on the last one.

👍 I'll take a look.

roderickvd · 2025-11-14T00:04:47Z

src/host/aaudio/mod.rs

+const CHANNEL_CONFIGS: [(i32, u16); 2] = [(CHANNEL_OUT_MONO, 1), (CHANNEL_OUT_STEREO, 2)];

 const SAMPLE_RATES: [i32; 13] = [
    5512, 8000, 11025, 16000, 22050, 32000, 44100, 48000, 64000, 88200, 96000, 176_400, 192_000,


I know this isn't yours, but now I read it I think that it should also support 12 and 24 kHz.

roderickvd · 2025-11-14T00:09:30Z

Thanks for your PR and efforts. I'm gonna merge this now, and add the 12/24 kHz after manually. Let me know if I'm wrong.

will3942 added 3 commits October 27, 2025 09:48

AAudio buffer size minimum should be detected using the PROPERTY_OUTP…

42fd371

…UT_FRAMES_PER_BUFFER on the AudioManager not using AudioTrack

Fix error handling

8f8a710

fmt

7a11e1c

will3942 changed the title ~~fix(aaudio): Correctly detect minimum buffer size.~~ fix(aaudio): Correctly detect minimum buffer size Oct 27, 2025

roderickvd added the platform - android label Oct 28, 2025

roderickvd requested changes Oct 28, 2025

View reviewed changes

will3942 added 2 commits October 29, 2025 12:03

Address PR comments

25fb184

fmt

b31029a

Update CHANGELOG

2b19dd8

irh added a commit to irh/cpal that referenced this pull request Nov 8, 2025

fix(aaudio): Correctly detect minimum buffer size (RustAudio#1039)

a8aa056

This is a squashed version of RustAudio#1039, 2b19dd8

irh added a commit to irh/cpal that referenced this pull request Nov 8, 2025

fix(aaudio): Correctly detect minimum buffer size (RustAudio#1039)

c685aa7

This is a squashed version of RustAudio#1039, 2b19dd8

roderickvd reviewed Nov 12, 2025

View reviewed changes

Fixes

c3239fe

will3942 mentioned this pull request Nov 12, 2025

Allow querying the buffer size of a Stream #1042

Open

will3942 added 2 commits November 13, 2025 10:47

Add a TODO for better error handling

f18aa74

Fmt

228a24a

roderickvd reviewed Nov 14, 2025

View reviewed changes

roderickvd merged commit a23a954 into RustAudio:master Nov 14, 2025
17 checks passed

fix(aaudio): Correctly detect minimum buffer size #1039

fix(aaudio): Correctly detect minimum buffer size #1039

Uh oh!

Conversation

will3942 commented Oct 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

roderickvd left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

will3942 commented Oct 28, 2025

Uh oh!

will3942 commented Oct 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

roderickvd left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

roderickvd commented Nov 12, 2025

Uh oh!

will3942 commented Nov 12, 2025

Uh oh!

will3942 commented Nov 12, 2025

Uh oh!

roderickvd commented Nov 13, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

roderickvd commented Nov 14, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

will3942 commented Oct 27, 2025 •

edited

Loading

will3942 commented Oct 29, 2025 •

edited

Loading