Audio HAL

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Die Audio-Hardware-Abstraktionsschicht (HAL) von Android verbindet die übergeordneten, audiospezifischen Framework-APIs in android.media mit den zugrunde liegenden Audiotreibern und der zugrunde liegenden Hardware. Die Audio-HAL definiert die Standardschnittstelle, die Audiodienste aufrufen. Es muss implementiert werden, damit die Audiohardware ordnungsgemäß funktioniert.

Diese Seite gibt einen Überblick über die Audio-HAL und liefert Einzelheiten zu ihren API- und Implementierungsanforderungen.

Audio-HAL-Schnittstelle

Die Audio-HAL-Schnittstelle wird mithilfe von HIDL in .hal Dateien und XSD -Schemas für die Konfigurationsdateien definiert, wie im Folgenden gezeigt.

audio_hal

Abbildung 1. Audio-HAL-Schnittstelle

Konfigurationsdateien

XML-Konfigurationsdateien für Audiorichtlinien und Audioeffekte gelten als Teil der Audio-HAL-Schnittstelle. Diese Dateien müssen ihren Schemas entsprechen, und die Konformität wird durch VTS-Tests verifiziert.

Als Teil der Implementierung der Audio-HAL müssen Sie eine Konfigurationsdatei für Audiorichtlinien erstellen , die die Audiotopologie beschreibt. Audio-HAL-Funktionen müssen in der Datei audio_policy_configuration.xml werden, damit das Framework sie verwenden kann.

Audio-HAL-API

Die Audio-HAL enthält die folgenden APIs:

  • Kern HAL
  • Effekte HAL
  • Gemeinsame HAL

Jede dieser APIs wird in den folgenden Abschnitten beschrieben.

Kern HAL

Die Core HAL ist die Haupt-API, die von AudioFlinger verwendet wird, um Audio abzuspielen und das Audio-Routing zu steuern. Einige der wichtigsten Schnittstellen sind wie folgt:

  • IDeviceFactory.hal ist der Einstiegspunkt in die API.
  • IDevice.hal und IPrimaryDevice.hal enthalten Methoden wie setMasterVolume oder openInputStream .
  • Streams sind unidirektional und werden von AudioFlinger zum Senden oder Empfangen von Audio an und von der HAL über IStream.hal , IStreamOut.hal und IStreamIn.hal .

In der folgenden Tabelle sind die Speicherorte nützlicher HAL-Core-Komponenten aufgeführt.

HAL-Kernkomponente Ort
Neueste Version der API /hardware/interfaces/audio/6.0
Typen, die für die neueste Core-HAL-API spezifisch sind /hardware/interfaces/audio/6.0/types.hal
XSD-Schema der Konfigurationsdatei für Audiorichtlinien /hardware/interfaces/audio/6.0/config/audio_policy_configuration.xsd

Die Standardimplementierung der Core-HAL-API ( /hardware/interfaces/audio/core/all-versions/default/ ) ist ein Wrapper um die Pre-Treble-HAL-Implementierung unter Verwendung älterer gemeinsam genutzter Bibliotheken . Die Standardimplementierung kann auch als Referenz betrachtet werden, wenn neue Versionen von Audio-HALs implementiert werden, die direkt mit Kernel-Treibern interagieren.

Effekte HAL

Die Effekt-HAL-API wird vom Effekt-Framework verwendet, um Audioeffekte zu steuern. Sie können auch Vorverarbeitungseffekte wie automatische Verstärkungsregelung und Rauschunterdrückung über die Effects HAL API konfigurieren.

Die folgende Tabelle listet die Position nützlicher HAL-Komponenten von Effects auf.

Beeinflusst die HAL-Komponente Ort
Neueste Version der API /hardware/interfaces/audio/effect/6.0/
Effect-Konfigurationsdatei XSD-Schema /hardware/interfaces/audio/effect/6.0/xml/audio_effects_conf.xsd

Weitere Informationen finden Sie in einer Beispielimplementierung der Effekt-HAL-API ( /hardware/interfaces/audio/effect/all-versions/default/ ) und im Abschnitt Audioeffekte .

Gemeinsame HAL

Die Common HAL ist eine Bibliothek gängiger Datentypen, die von den Core- und Effects-HAL-APIs verwendet werden. Es hat keine Schnittstellen und keine zugehörigen VTS-Tests, da es nur Datenstrukturen definiert. Die Common HAL API enthält Folgendes:

  • Definitionen ( /hardware/interfaces/audio/common/6.0/types.hal ), die von den Kern- und Effekt-APIs gemeinsam genutzt werden
  • Dienstprogramme ( /hardware/interfaces/audio/common/all-versions ) zur Unterstützung der Codierung gegen HIDL-APIs für Implementierungen, Clients und Tests

Anforderungen

Neben der Implementierung der Audio-HAL und der Erstellung der Audio-Richtlinien-Konfigurationsdatei müssen die folgenden HAL-Anforderungen eingehalten werden:

  • Wenn die Erfassung für Sound Trigger (Erfassung aus dem Hotword-DSP-Puffer) von einem Eingabeprofil unterstützt wird, muss die Implementierung die Anzahl aktiver Streams in diesem Profil unterstützen, die der Anzahl gleichzeitiger Sitzungen entspricht, die von Sound Trigger HAL unterstützt werden.
  • Gleichzeitiges Senden von Sprachanrufen und Erfassung vom Anwendungsprozessor, wie auf der Seite „ Gleichzeitige Erfassung “ beschrieben.

Updates für Audio HAL V7

Um Abwärtskompatibilitätsprobleme zu beheben, ist Stable AIDL für alle HAL-Änderungen ab Android 13 obligatorisch. Um die AIDL-Einführung in Android 13 und höher zu unterstützen und zu verbessern, tut Audio HAL V7 Folgendes:

  • Vereinheitlicht die vom Framework und HAL verwendeten Datenmodelle.
  • Minimiert die Duplizierung zwischen HIDL-Datentypen (Enumerationen) und dem XML-Schema, das für die Audiorichtlinienkonfiguration verwendet wird.

Insbesondere werden in Audio HAL V7 Änderungen in den folgenden Bereichen vorgenommen:

Diese Änderungen werden in den jeweiligen Abschnitten ausführlicher besprochen.

Aufzählungen

Ab Audio HAL V7 werden Aufzählungstypen, die in der Audiorichtlinien-Konfigurationsdatei verwendet werden, nur im XSD-Schema und nicht in HIDL definiert.

In Audio HAL V6 werden Werte von Enum-Typen (wie AudioFormat ) in types.hal auch im XSD-Schema der Audiorichtlinien-Konfigurationsdatei definiert, wodurch eine Duplizierung entsteht. Um dies in V7 zu vermeiden, werden die Aufzählungstypen in string geändert und alle möglichen Aufzählungswerte werden stattdessen im XSD-Schema aufgelistet.

In Abbildung 2 finden Sie einen Vergleich einiger Änderungen am Aufzählungstyp „ AudioFormat “ in V7.

audioformat-change

Abbildung 2. Vergleich einiger Änderungen an der Aufzählung AudioFormat

In der folgenden Liste finden Sie die Enum-Typen, die in String konvertiert wurden:

  • AudioChannelMask
  • AudioContentType
  • AudioDevice : vom Hersteller erweiterbar
  • AudioFormat : vom Hersteller erweiterbar
  • AudioGainMode
  • AudioSource
  • AudioStreamType
  • AudioUsage

String-Enum-Werte übergeben

Zeichenfolgenwerte werden zum Übertragen von Informationen als Aufzählungswerte über die HAL-Schnittstellengrenze hinweg verwendet. Sowohl das Framework als auch der HAL-Wrapper verwenden ganzzahlige Enum-Werte zur Implementierung der Geschäftslogik und verwenden den in Abbildung 3 dargestellten Konvertierungsansatz.

audio-passing-values

Abbildung 3. Übergeben von String-Enum-Werten

Um beispielsweise einen Wert des Audioformattyps vom Framework an den Anbieter zu übergeben:

  1. Der Enum-Wert von AudioFormat wird in libaudiohal in einen String-Wert konvertiert und an die HAL übergeben.
  2. Auf der HAL-Seite konvertiert der Standard-Wrapper die Zeichenfolge in einen Enum-Wert, der an die Legacy-HAL übergeben wird.

XML-Schemaänderungen

Vollständige Listen von Aufzählungswerten in der XML-Schemadefinition (XSD) ermöglichen eine bessere Validierung der XML-Datei für die Audiorichtlinienkonfiguration durch VTS. Änderungen werden in der Audiorichtlinien-Konfigurationsdatei vorgenommen, die mit HAL V7 verwendet wird, um XSD zu entsprechen.

In V7 wird anstelle von , (Komma) und | ein Standardzeichen (Leerzeichen) verwendet, um Wertelisten in Attributen (wie Abtastraten, Kanalmasken und Flags) abzugrenzen (vertikaler Balken) Symbole, die in V6 und darunter verwendet werden. Wie im folgenden Beispiel zu sehen ist, wird ein Leerzeichen verwendet, um die Werteliste für channelMasks zu begrenzen:

<profile channelMasks="AUDIO_CHANNEL_OUT_STEREO AUDIO_CHANNEL_OUT_MONO" … />

Um die Symboländerungen vorzunehmen, verwenden Sie ein automatisches Konvertierungsskript namens update_audio_policy_config.sh . Sehen Sie sich den folgenden Befehl an, um eine V6-Audiorichtlinien-Konfigurationsdatei in eine V7-Version für das Pixel 5 (Redfin)-Gerät zu konvertieren:

hardware/interfaces/audio/7.0/config/update_audio_policy_config.sh \
device/google/redfin/audio/audio_policy_configuration.xml 6.0

Datentypen

Einige Datenstrukturen wurden in V7 neu definiert, um doppelte Definitionen zu minimieren. Wiederholte Tupel von Datenelementen werden zu wiederverwendbaren Strukturen zusammengruppiert. Diese Datenstrukturen verwenden die neuesten HIDL-Funktionen wie sichere Vereinigungen.

Beispielsweise wird in V6 und darunter häufig ein Tripel aus <format, sampling rate, channel mask> in den HIDL-Schnittstellen und -Typen verwendet. Um diese Redundanz zu beseitigen, sind in V7 der AudioConfigBase -Datentyp und andere Datentypen wie folgt definiert:

  • AudioConfigBase := <format, sampling rate, channel mask>

  • AudioConfigBaseOptional := <[fmt], [sampl. rate], [chan. mask]>

    Wird von AudioConfig , AudioOffloadInfo , AudioPortConfig verwendet

  • AudioProfile := <format, {sampling rates}, {channel masks}>

    ersetzt lose Sammlungen in AudioPort/PortConfig

  • AudioPortExtendedInfo := device | mix | session

    ersetzt Unions in AudioPort/PortConfig

Anbieter-Tags

Zusätzlich zu Gerätetypen und -formaten können Anbieter benutzerdefinierte Tags für Audiotrack-Metadaten hinzufügen.

Für Wiedergabe- und Aufnahme-Track-Metadaten können Anbieter ihre eigenen Tags, die zum Hinzufügen von Attributen zu Audio-I/O-Streams verwendet werden, von den Apps an die HAL übergeben.

Hersteller-Tags für Wiedergabe-Track-Metadaten werden wie im folgenden Beispiel gezeigt hinzugefügt:

struct PlaybackTrackMetadata {
…
    /** Tags from AudioTrack audio attributes */
    vec<AudioTag> tags;
};

Die RecordTrackMetadata Struktur wird auf ähnliche Weise implementiert, indem Tags hinzugefügt werden, die für die Metadaten der Aufzeichnungsspur spezifisch sind.

Namespace für Anbietererweiterungen

Ab HAL V7 erfordern Anbietererweiterungen ein zusätzliches {vendor} -Präfix, das in V6 nicht erforderlich ist. Damit das Präfix {vendor} gültig ist, muss es aus drei oder mehr alphanumerischen Zeichen bestehen.

Verwenden Sie das folgende Format in V7:

VX_{ vendor }_{ letters/numbers }

Im Folgenden finden Sie einige Beispiele für gültige V7-Anbietererweiterungen:

  • VX_ GOOGLE _VR
  • VX_ QCI _AMBIENT_MIC

Versionsinformation

In der folgenden Tabelle ist die HAL-Versionsnummer für jede Android-Version aufgeführt.

Android-Version HAL-Version
Android 13 7.1
Android 12 7.0
Android 11 6.0
Android 10 5.0
Android 9 4.0
Android 8 2.0