Design für reduzierte Latenz

Anbieter können zwei wichtige Funktionen implementieren, um die Audiolatenz zu verringern:

  • FAST Mixer in AudioFlinger: Diese Funktion wurde in Android 4.1 eingeführt und unterstützt Apps, die Java AudioTrack und AAudio verwenden. Der FAST Mixer erfordert nur minimale Änderungen an der öffentlichen Client-API oder der HAL-API.
  • AAudio MMAP: Diese Funktion wurde in Android 8.1 eingeführt und ermöglicht systemeigenen Apps, über AAudio eine noch geringere Latenz zu erzielen. Weitere Informationen finden Sie unter AAudio und MMAP.

Auf dieser Seite wird das ursprüngliche Design der Audiolatenz beschrieben, das sich im Laufe der Zeit weiterentwickelt hat. Ein gutes Verständnis dieses Designs ist für Geräte-OEMs und SoC-Anbieter entscheidend, um eine korrekte Implementierung auf ihren jeweiligen Geräten und Chipsätzen zu gewährleisten. Diese Seite richtet sich nicht an App-Entwickler.

Track-Erstellung

Der Client kann optional Bit AUDIO_OUTPUT_FLAG_FAST im Parameter audio_output_flags_t des AudioTrack-C++-Konstruktors oder AudioTrack::set() festlegen. Derzeit sind das nur folgende Clients:

Die AudioTrack-C++-Implementierung prüft die AUDIO_OUTPUT_FLAG_FAST-Anfrage und kann sie optional auf Clientebene ablehnen. Wenn die Anfrage weitergeleitet werden soll, geschieht dies über das TRACK_FAST-Bit des track_flags_t-Parameters der IAudioTrack-Fabrikmethode IAudioFlinger::createTrack().

Der AudioFlinger-Audioserver prüft die TRACK_FAST-Anfrage und kann sie optional auf Serverebene ablehnen. Der Client wird über Bit CBLK_FAST des gemeinsamen Speichersteuerblocks darüber informiert, ob die Anfrage akzeptiert wurde.

Die Entscheidung wird durch folgende Faktoren beeinflusst:

  • Vorhandensein eines Threads für schnelle Mixer für diese Ausgabe (siehe unten)
  • Abtastrate für Tracks
  • Vorhandensein eines Client-Threads zum Ausführen von Callback-Handlern für diesen Track
  • Größe des Track-Puffers
  • Verfügbare Fast-Track-Slots (siehe unten)

Wenn die Anfrage des Kunden akzeptiert wurde, wird sie als Fast Track bezeichnet. Andernfalls wird sie als normaler Track bezeichnet.

Mixer-Threads

Wenn AudioFlinger einen normalen Mixer-Thread erstellt, wird entschieden, ob auch ein schneller Mixer-Thread erstellt wird. Sowohl der normale als auch der schnelle Mixer sind nicht einem bestimmten Track, sondern einer Gruppe von Tracks zugeordnet. Es gibt immer einen normalen Mixer-Thread. Der schnelle Mixer-Thread, sofern vorhanden, ist dem normalen Mixer-Thread untergeordnet und wird von ihm gesteuert.

Schneller Mixer-Thread

Funktionen

Der schnelle Mixer-Thread bietet die folgenden Funktionen:

  • Mischen des Submix des normalen Mixers und von bis zu sieben Client-Fast-Tracks
  • Dämpfung pro Track

Ausgelassene Funktionen:

  • Conversion der Abtastrate nach Track
  • Nach Track-Effekten
  • Nach Mix-Effekten

Punkt

Der schnelle Mixer wird regelmäßig ausgeführt. Der empfohlene Zeitraum beträgt zwei bis drei Millisekunden oder bei Bedarf etwas mehr (5 ms), um die Stabilität der Planung zu gewährleisten. Diese Zahl wurde so gewählt, dass die Gesamtlatenz unter Berücksichtigung der gesamten Buffer-Pipeline in der Größenordnung von 10 ms liegt. Kleinere Werte sind möglich, können aber je nach Vorhersagbarkeit der CPU-Planung zu einem erhöhten Stromverbrauch und einer höheren Wahrscheinlichkeit von Glitches führen. Größere Werte sind möglich (bis zu 20 ms), führen aber zu einer höheren Gesamtlatenz und sollten daher vermieden werden.

Planung

Der schnelle Mixer wird mit erhöhter SCHED_FIFO-Priorität ausgeführt. Es benötigt sehr wenig CPU-Zeit, muss aber oft und mit geringem Scheduling-Jitter ausgeführt werden. Jitter gibt die Schwankung der Zykluszeit an. Er ist die Differenz zwischen der tatsächlichen und der erwarteten Zykluszeit. Wenn die Ausführung zu spät erfolgt, kommt es aufgrund von Underruns zu Glitches. Wenn Sie zu früh mit der Ausführung beginnen, kann es zu Problemen kommen, da Daten aus einem Fast Track abgerufen werden, bevor Daten für den Track verfügbar sind.

Blockierungen

Im Idealfall wird der schnelle Mixer-Thread nie blockiert, außer bei HAL write(). Andere Fälle von Blockierungen im schnellen Mixer gelten als Fehler. Insbesondere werden Mutexe vermieden. Stattdessen werden nicht blockierende Algorithmen (auch als sperrenfreie Algorithmen bezeichnet) verwendet. Weitere Informationen zu diesem Thema finden Sie unter Prioritätsinversion vermeiden.

Beziehung zu anderen Komponenten

Der schnelle Mixer hat wenig direkten Kontakt zu Clients. Insbesondere werden keine Vorgänge auf Binderebene erkannt, aber auf den Shared Memory Control Block des Clients wird zugegriffen.

Der schnelle Mixer empfängt Befehle vom normalen Mixer über eine Statuswarteschlange.

Abgesehen vom Abrufen von Trackdaten erfolgt die Interaktion mit Kunden über den normalen Mixer.

Die primäre Senke des schnellen Mixer ist der Audio-HAL.

Normaler Mixer

Funktionen

Alle Funktionen sind aktiviert:

  • Bis zu 32 Tracks
  • Dämpfung pro Track
  • Conversion der Abtastrate nach Track
  • Effektverarbeitung

Punkt

Der Zeitraum wird als das erste ganzzahlige Vielfache des schnellen Mixerzeitraums berechnet, das größer oder gleich 20 ms ist.

Planung

Der normale Mixer wird mit erhöhter SCHED_OTHER-Priorität ausgeführt.

Blockierungen

Der normale Mixer darf blockieren und tut dies oft an verschiedenen Mutexes sowie an einer blockierenden Pipe, um seinen Submix zu schreiben.

Beziehung zu anderen Komponenten

Der normale Mixer interagiert intensiv mit der Außenwelt, einschließlich Binder-Threads, Audio Policy Manager, schneller Mixer-Thread und Client-Tracks.

Die Senke des normalen Mixers ist eine blockierende Pipe zum Track 0 des schnellen Mixers.

Flaggen

AUDIO_OUTPUT_FLAG_FAST Bit ist ein Hint. Es gibt keine Garantie, dass die Anfrage erfüllt wird.

AUDIO_OUTPUT_FLAG_FAST ist ein Konzept auf Clientebene. Es wird nicht auf dem Server angezeigt.

TRACK_FAST ist ein Client-zu-Server-Konzept.