Realtime DSP on Android — what AAudio gets right

For most of the last decade, “realtime audio on Android” was a punchline. OpenSL ES was unsupported, latency was unpredictable, and the cross-device variance made it cheaper to build for iOS and ignore Android entirely.

That’s no longer the right read. AAudio — and the broader Android audio pipeline as of 14+ — is a credible realtime stack, and on flagship devices the round-trip latency is now comparable to the Apple side. There are still rough edges, and pretending otherwise is the fastest way to ship a buggy app, but the platform deserves a second look.

What changed

Three things, in order of impact:

1. AAudio matured. Exclusive mode, low-latency streams, and a sensible callback model finally landed. The API surface is small and consistent enough that a wrapper isn’t strictly necessary, though Oboe is still the most defensible choice for production code.
2. Bluetooth got serious. LE Audio and the underlying Bluetooth stack are now usable for music and call audio with sane latencies. This matters more than the marketing suggests — it’s the difference between a hearing-support app that works in the wild and one that doesn’t.
3. The variance narrowed. Mid-tier devices used to be a special hell. They’re not equal to flagships, but the latency distribution has tightened enough that you can target a real budget tier without designing two different signal paths.

What still bites

• Sample-rate negotiation. You can ask for 48k. You can get 48k. You can also get something else, depending on the device’s output. Always check, don’t assume.
• Power management. Doze mode and battery savers will quietly kill or pause your audio thread. Test with battery saver on. Always.
• Bluetooth handoffs. Switching from wired to BT mid-stream is still a hazard. Build for the recovery path, not the happy path.
• Cross-device callback timing. The “minimum frames” you negotiate is a hint, not a promise. Wrap your audio loop in something defensive.

A pragmatic stack

For a realtime audio app on Android today, the boring-but-correct choices look like this:

• Native audio core in C++, behind Oboe.
• DSP in either C++ or Rust (if you’re comfortable in Rust, the FFI cost is manageable).
• Audio thread does only the audio thread’s job. No allocations, no locks, no JNI calls into Java, no logging in the hot path.
• Hot reload of parameters via lock-free queues. Don’t share state via mutexes.
• Cross-platform via JUCE or Oboe + your own minimal abstraction. If you’re also targeting iOS / web, JUCE remains the path of least resistance.

Where AAudio still shines

The places where AAudio actually outperforms expectations are the ones nobody markets:

• Voice and call routing. AudioManager routing is still ugly, but the underlying behaviour is reliable enough to build call-quality apps without surprise drops.
• Hearing-aid integration. ASHA and now LE Audio give you real, low-latency paths to hearing devices. This is the corner of the platform that’s genuinely ahead of where it was even two years ago.
• Cross-app routing. Power users use routing apps. Don’t fight them. Build around them.

What this means for AudioLab

We build on Android because the audio platform is now good enough, the hardware spread is real, and the accessibility surface is where AAudio matters most. Our HearLab companion is Android-first because the routing layer is something we can actually surface to users.

If you’re writing an audio app and want a sober view on whether to target Android, the answer in 2026 is: yes, with adult supervision.