/insights · Engineering
Echtzeit-DSP unter Android: was AAudio richtig macht
AAudio + AudioWorklet ist mittlerweile ein glaubwürdiger Echtzeit-Audiostack. Ein kurzer Rundgang durch die rauen Kanten und die Teile, die einfach funktionieren.
Den größten Teil des letzten Jahrzehnts war „Echtzeit-Audio unter Android” eine Pointe. OpenSL ES wurde nicht unterstützt, die Latenz war unvorhersehbar, und die Streuung zwischen den Geräten machte es günstiger, für iOS zu bauen und Android schlicht zu ignorieren.
Das ist nicht mehr die richtige Einschätzung. AAudio (und die breitere Android-Audiopipeline ab 14+) ist ein glaubwürdiger Echtzeit-Stack, und auf Flaggschiff-Geräten ist die Round-Trip-Latenz inzwischen mit der auf der Apple-Seite vergleichbar. Es gibt noch raue Kanten, und so zu tun, als gäbe es sie nicht, ist der schnellste Weg, eine fehlerhafte App auszuliefern, aber die Plattform verdient einen zweiten Blick.
Was sich geändert hat
Drei Dinge, in der Reihenfolge ihrer Wirkung:
- AAudio ist gereift. Exklusivmodus, Low-Latency-Streams und ein vernünftiges Callback-Modell sind endlich angekommen. Die API-Oberfläche ist klein und konsistent genug, dass ein Wrapper streng genommen nicht zwingend nötig ist, auch wenn Oboe für Produktionscode weiterhin die am besten zu rechtfertigende Wahl bleibt.
- Bluetooth wurde ernst genommen. LE Audio und der zugrunde liegende Bluetooth-Stack sind jetzt für Musik- und Gesprächsaudio mit vernünftigen Latenzen nutzbar. Das wiegt schwerer, als das Marketing vermuten lässt, es ist der Unterschied zwischen einer Hörunterstützungs-App, die im Feld funktioniert, und einer, die es nicht tut.
- Die Streuung hat sich verringert. Geräte der Mittelklasse waren früher eine besondere Hölle. Sie sind nicht gleichwertig mit Flaggschiffen, aber die Latenzverteilung ist eng genug geworden, dass man eine echte Budget-Klasse anvisieren kann, ohne zwei verschiedene Signalpfade entwerfen zu müssen.
Was noch beißt
- Aushandlung der Sample-Rate. Du kannst 48k anfordern. Du kannst 48k bekommen. Du kannst je nach Ausgabe des Geräts auch etwas anderes bekommen. Prüfe immer nach, setze nichts voraus.
- Energieverwaltung. Doze-Modus und Akkusparmodi werden deinen Audiothread klammheimlich beenden oder pausieren. Teste mit eingeschaltetem Akkusparmodus. Immer.
- Bluetooth-Übergaben. Mitten im Stream von kabelgebunden auf BT umzuschalten, ist nach wie vor eine Gefahrenquelle. Baue für den Wiederherstellungspfad, nicht für den Happy Path.
- Callback-Timing zwischen Geräten. Die „Mindestanzahl an Frames”, die du aushandelst, ist ein Hinweis, kein Versprechen. Umhülle deine Audioschleife mit etwas Defensivem.
Ein pragmatischer Stack
Für eine Echtzeit-Audio-App unter Android sehen die langweiligen-aber-korrekten Entscheidungen heute so aus:
- Native Audio-Core in C++, hinter Oboe.
- DSP entweder in C++ oder Rust (wenn du dich in Rust wohlfühlst, sind die FFI-Kosten überschaubar).
- Der Audiothread macht nur die Aufgabe des Audiothreads. Keine Allokationen, keine Locks, keine JNI-Aufrufe nach Java, kein Logging im Hot Path.
- Hot Reload von Parametern über lock-free Queues. Teile State nicht über Mutexe.
- Cross-Platform über JUCE oder Oboe + deine eigene minimale Abstraktion. Wenn du auch iOS / Web anvisierst, bleibt JUCE der Weg des geringsten Widerstands.
Wo AAudio nach wie vor glänzt
Die Stellen, an denen AAudio die Erwartungen tatsächlich übertrifft, sind die, die niemand bewirbt:
- Sprach- und Gesprächs-Routing. AudioManager-Routing ist immer noch hässlich, aber das zugrunde liegende Verhalten ist zuverlässig genug, um Apps in Gesprächsqualität ohne überraschende Aussetzer zu bauen.
- Hörgeräte-Integration. ASHA und jetzt LE Audio geben dir echte, latenzarme Pfade zu Hörgeräten. Das ist die Ecke der Plattform, die wirklich weiter ist, als sie noch vor zwei Jahren war.
- App-übergreifendes Routing. Power-User nutzen Routing-Apps. Bekämpfe sie nicht. Baue um sie herum.
Was das für AudioLab bedeutet
Wir bauen auf Android, weil die Audioplattform jetzt gut genug ist, die Hardware-Streuung real ist und die Barrierefreiheits-Oberfläche genau dort liegt, wo AAudio am meisten zählt. Unser HearLab-Begleiter ist Android-first, weil die Routing-Schicht etwas ist, das wir den Nutzern tatsächlich sichtbar machen können.
Wenn du eine Audio-App schreibst und eine nüchterne Einschätzung dazu willst, ob du Android anvisieren solltest, lautet die Antwort 2026: ja, unter erwachsener Aufsicht.
More in Engineering
-
Android-Audioentwicklung im Jahr 2026: der Leitfaden für Entwickler
Ein praxisnaher Entwicklerleitfaden zum Bau ernsthafter Audioanwendungen auf Android im Jahr 2026: AAudio, Oboe, JUCE, Latenzbudgets, Routing zu Hörgeräten, AudioWorklet-Äquivalente und die Teile der Plattform, die endlich einfach funktionieren.
-
Echtzeit-Audio im Browser: was 2026 tatsächlich möglich macht
Die ehrliche Unter- und Obergrenze für Browser-Audio im Jahr 2026: AudioWorklet-Latenz, WebGPU-Inferenz, MediaDevices-Aufnahme, die Lücken, die gegenüber Native noch bestehen, und die Lücken, die sich endlich geschlossen haben.
-
WebAudio vs. native: wo die Grenze 2026 wirklich verläuft
WebAudio hat die Schwelle von "nur für Demos" zu "produktionsreif für viele Anwendungsfälle" überschritten. Hier steht, wo es noch zu kurz greift und wo es inzwischen das richtige Werkzeug ist.