DSP temps réel sur Android : ce qu'AAudio réussit

Pendant la majeure partie de la dernière décennie, « l’audio temps réel sur Android » prêtait à rire. OpenSL ES n’était pas pris en charge, la latence était imprévisible, et les écarts entre appareils rendaient plus économique de développer pour iOS et d’ignorer purement et simplement Android.

Ce n’est plus la bonne lecture. AAudio (et l’ensemble du pipeline audio Android à partir de la version 14+) constitue une pile temps réel crédible, et sur les appareils haut de gamme, la latence aller-retour est désormais comparable à celle du côté Apple. Il reste des aspérités, et prétendre le contraire est le moyen le plus rapide de livrer une application bourrée de bugs, mais la plateforme mérite un second regard.

Ce qui a changé

Trois choses, par ordre d’impact :

1. AAudio a mûri. Le mode exclusif, les flux à faible latence et un modèle de callback sensé sont enfin arrivés. La surface de l’API est suffisamment réduite et cohérente pour qu’un wrapper ne soit pas strictement nécessaire, même si Oboe reste le choix le plus défendable pour du code de production.
2. Le Bluetooth est devenu sérieux. LE Audio et la pile Bluetooth sous-jacente sont maintenant utilisables pour l’audio musical et vocal avec des latences raisonnables. Cela compte davantage que ne le laisse entendre le marketing : c’est la différence entre une application d’aide auditive qui fonctionne sur le terrain et une qui ne fonctionne pas.
3. Les écarts se sont resserrés. Les appareils de milieu de gamme étaient autrefois un enfer à part. Ils ne valent pas les modèles haut de gamme, mais la distribution de la latence s’est suffisamment resserrée pour viser un vrai segment d’entrée de gamme sans concevoir deux chemins de signal différents.

Ce qui mord encore

• Négociation de la fréquence d’échantillonnage. Vous pouvez demander du 48k. Vous pouvez obtenir du 48k. Vous pouvez aussi obtenir autre chose, selon la sortie de l’appareil. Vérifiez toujours, ne présumez rien.
• Gestion de l’énergie. Le mode Doze et les économiseurs de batterie vont discrètement tuer ou mettre en pause votre thread audio. Testez avec l’économiseur de batterie activé. Toujours.
• Transferts Bluetooth. Passer du filaire au BT en plein flux reste un danger. Construisez pour le chemin de récupération, pas pour le happy path.
• Timing des callbacks entre appareils. Le « nombre minimum de frames » que vous négociez est une indication, pas une promesse. Enveloppez votre boucle audio dans quelque chose de défensif.

Une pile pragmatique

Pour une application audio temps réel sur Android aujourd’hui, les choix ennuyeux-mais-corrects ressemblent à ceci :

• Cœur audio natif en C++, derrière Oboe.
• DSP en C++ ou en Rust (si vous êtes à l’aise en Rust, le coût du FFI est gérable).
• Le thread audio ne fait que le travail du thread audio. Pas d’allocations, pas de verrous, pas d’appels JNI vers Java, pas de logging dans le hot path.
• Rechargement à chaud des paramètres via des files lock-free. Ne partagez pas l’état via des mutex.
• Multiplateforme via JUCE ou Oboe + votre propre abstraction minimale. Si vous visez aussi iOS / le web, JUCE reste la voie de moindre résistance.

Là où AAudio brille encore

Les domaines où AAudio dépasse réellement les attentes sont ceux que personne ne met en avant :

• Routage de la voix et des appels. Le routage via AudioManager reste laid, mais le comportement sous-jacent est suffisamment fiable pour construire des applications de qualité téléphonique sans coupures surprises.
• Intégration des aides auditives. ASHA et désormais LE Audio vous offrent de véritables chemins à faible latence vers les appareils auditifs. C’est le coin de la plateforme qui est réellement en avance par rapport à ce qu’il était il y a encore deux ans.
• Routage inter-applications. Les utilisateurs avancés se servent d’applications de routage. Ne les combattez pas. Construisez autour d’elles.

Ce que cela signifie pour AudioLab

Nous développons sur Android parce que la plateforme audio est désormais assez bonne, que la diversité du matériel est réelle, et que la surface d’accessibilité se situe précisément là où AAudio compte le plus. Notre compagnon HearLab est Android-first parce que la couche de routage est quelque chose que nous pouvons réellement exposer aux utilisateurs.

Si vous écrivez une application audio et souhaitez un avis lucide sur l’opportunité de viser Android, la réponse en 2026 est : oui, sous supervision adulte.