Realtime DSP op Android: wat AAudio goed doet

Het grootste deel van het afgelopen decennium was “realtime audio op Android” een mikpunt van spot. OpenSL ES werd niet ondersteund, de latency was onvoorspelbaar, en de verschillen tussen apparaten maakten het goedkoper om voor iOS te bouwen en Android volledig te negeren.

Dat is niet langer de juiste inschatting. AAudio (en de bredere Android-audiopipeline vanaf 14+) is een geloofwaardige realtime-stack, en op vlaggenschiptoestellen is de round-trip-latency inmiddels vergelijkbaar met die aan de Apple-kant. Er zijn nog steeds ruwe randjes, en doen alsof dat niet zo is is de snelste manier om een app met bugs uit te brengen, maar het platform verdient een tweede blik.

Wat er veranderd is

Drie dingen, in volgorde van impact:

1. AAudio is volwassen geworden. Exclusieve modus, low-latency streams en een verstandig callback-model zijn eindelijk gearriveerd. Het API-oppervlak is klein en consistent genoeg dat een wrapper strikt genomen niet noodzakelijk is, al blijft Oboe de meest verdedigbare keuze voor productiecode.
2. Bluetooth is serieus geworden. LE Audio en de onderliggende Bluetooth-stack zijn nu bruikbaar voor muziek- en gespreksaudio met redelijke latencies. Dit telt zwaarder dan de marketing suggereert: het is het verschil tussen een gehoorondersteunende app die in de praktijk werkt en eentje die dat niet doet.
3. De spreiding is kleiner geworden. Toestellen uit het middensegment waren vroeger een speciale hel. Ze zijn niet gelijk aan vlaggenschepen, maar de latency-verdeling is genoeg verkrapt dat je een echte budgetlaag kunt aansturen zonder twee verschillende signaalpaden te ontwerpen.

Wat nog steeds bijt

• Onderhandeling over de sample rate. Je kunt om 48k vragen. Je kunt 48k krijgen. Je kunt ook iets anders krijgen, afhankelijk van de output van het toestel. Controleer altijd, ga er niet vanuit.
• Energiebeheer. Doze-modus en accubesparing zullen je audiothread stilletjes afsluiten of pauzeren. Test met accubesparing aan. Altijd.
• Bluetooth-overdrachten. Midden in een stream van bekabeld naar BT overschakelen is nog steeds een valkuil. Bouw voor het herstelpad, niet voor het happy path.
• Callback-timing tussen toestellen. Het “minimum aantal frames” waarover je onderhandelt is een hint, geen belofte. Verpak je audioloop in iets defensiefs.

Een pragmatische stack

Voor een realtime-audio-app op Android vandaag de dag zien de saaie-maar-correcte keuzes er zo uit:

• Native audiokern in C++, achter Oboe.
• DSP in C++ of Rust (als je je thuis voelt in Rust, zijn de FFI-kosten beheersbaar).
• De audiothread doet alleen het werk van de audiothread. Geen allocaties, geen locks, geen JNI-calls naar Java, geen logging in het hot path.
• Hot reload van parameters via lock-free queues. Deel state niet via mutexen.
• Cross-platform via JUCE of Oboe + je eigen minimale abstractie. Als je ook iOS / web target, blijft JUCE de weg van de minste weerstand.

Waar AAudio nog steeds uitblinkt

De plekken waar AAudio de verwachtingen daadwerkelijk overtreft, zijn de plekken die niemand vermarkt:

• Spraak- en gespreksrouting. AudioManager-routing is nog steeds lelijk, maar het onderliggende gedrag is betrouwbaar genoeg om apps van belkwaliteit te bouwen zonder onverwachte uitval.
• Integratie met hoortoestellen. ASHA en nu LE Audio geven je echte, low-latency paden naar hoortoestellen. Dit is de hoek van het platform die werkelijk verder is dan waar hij zelfs twee jaar geleden stond.
• Routing tussen apps. Power users gebruiken routing-apps. Bestrijd ze niet. Bouw eromheen.

Wat dit betekent voor AudioLab

We bouwen op Android omdat het audioplatform nu goed genoeg is, de hardwarespreiding reëel is, en het toegankelijkheidsoppervlak juist daar ligt waar AAudio het meest telt. Onze HearLab-companion is Android-first omdat de routinglaag iets is dat we daadwerkelijk aan gebruikers kunnen tonen.

Als je een audio-app schrijft en een nuchtere kijk wilt op de vraag of je Android moet targeten, is het antwoord in 2026: ja, met volwassen toezicht.