Audio-HAL

Android Audio - Hardware Abstraction Layer (HAL) verbindet die auf höherer Ebene, audio-spezifischen Framework - APIs in android.media auf die zugrunde liegenden Audio-Treiber und Hardware. Die Audio HAL definiert die Standardschnittstelle, die von Audiodiensten aufgerufen wird. Es muss implementiert werden, damit die Audiohardware richtig funktioniert.

Diese Seite bietet einen Überblick über die Audio-HAL und enthält Details zu den API- und Implementierungsanforderungen.

Audio-HAL-Schnittstelle

Die Audio - HAL - Schnittstelle wird mit definierten HIDL in .hal Dateien und XSD - Schemata für die Konfigurationsdateien, wie folgt dargestellt:

audio_hal

Abbildung 1: Audio - Schnittstelle HAL

Konfigurationsdateien

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

Als Teil des Audio - HAL zu implementieren, müssen Sie eine erstellen Audio-Richtlinienkonfigurationsdatei , die die Audio-Topologie beschreibt. Audio HAL - Funktionen müssen in der deklariert werden audio_policy_configuration.xml für das Framework - Datei , sie zu benutzen.

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 Eintrittspunkt in die API.
  • IDevice.hal und IPrimaryDevice.hal enthalten Methoden wie setMasterVolume oder openInputStream .
  • Streams ist unidirektional und wird von AudioFlinger zum Senden oder Empfangen von Audio- und von der HAL durch IStream.hal , IStreamOut.hal und IStreamIn.hal .

In der folgenden Tabelle sind die Positionen nützlicher Core HAL-Komponenten aufgeführt:

HAL-Kernkomponente Standort
Neueste API-Version /hardware/interfaces/audio/6.0
Spezifische Typen für die neueste Core HAL API /hardware/interfaces/audio/6.0/types.hal
XSD-Schema der Audiorichtlinienkonfigurationsdatei /hardware/interfaces/audio/6.0/config/audio_policy_configuration.xsd

Die Standardimplementierung des Core - HAL API ( /hardware/interfaces/audio/core/all-versions/default/ ) ist ein Wrapper um Pre-Treble HAL Implementierung mit Bibliotheken Erbe geteilt . Die Standardimplementierung kann auch als Referenz angesehen werden, wenn neue Versionen von Audio-HALs implementiert werden, die direkt mit Kerneltreibern interagieren.

Effekte HAL

Die Effects HAL API wird vom Effekt-Framework verwendet, um Audioeffekte zu steuern. Sie können auch configure Pre-Processing - Effekte wie die automatische Verstärkungsregelung und Rauschunterdrückung durch die Effekte HAL API.

In der folgenden Tabelle sind die Positionen nützlicher HAL-Komponenten von Effects aufgeführt:

Effekte HAL-Komponente Standort
Neueste API-Version /hardware/interfaces/audio/effect/6.0/
Effekt Konfigurationsdatei XSD-Schema /hardware/interfaces/audio/effect/6.0/xml/audio_effects_conf.xsd

Weitere Informationen, eine Beispielimplementierung der Effects API ( /hardware/interfaces/audio/effect/all-versions/default/ ) und die Audio - Effekte Sektion.

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 ) geteilt durch den Kern und Effekt - APIs.
  • Utilities ( /hardware/interfaces/audio/common/all-versions ) , um Hilfe verwendete Codierung gegen HIDL APIs für Implementierungen, Kunden und Tests.

Anforderungen

Neben der Implementierung der Audio-HAL und der Erstellung der Audiorichtlinien-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 der aktiven Streams in diesem Profil unterstützen, die der Anzahl gleichzeitiger Sitzungen entspricht, die von Sound Trigger HAL unterstützt werden.
  • Concurrency von Sprachanruf TX und Erfassung von dem Anwendungsprozessor , wie auf der detaillierte Concurrent Capture - Seite.

Updates zum Audio HAL V7

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

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

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

Diese Änderungen werden in den jeweiligen Abschnitten genauer beschrieben.

Aufzählungen

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

In Audio-HAL V6, Werte von enum (wie AudioFormat ) in types.hal sind auch in dem Audio-Richtlinienkonfigurationsdatei XSD - Schema, wodurch eine Verdoppelung definiert. Um dies zu vermeiden in V7, die enum sind Typen geändert string und alle möglichen Aufzählungswerte werden im XSD - Schema statt aufgelistet.

Siehe Abbildung 1 für einen Vergleich von einige der Änderungen an den AudioFormat enum in V7:

audioformat-change

Abbildung 1: Vergleich von einige der Änderungen an das AudioFormat enum

Beachten Sie die folgende Liste für die enum die konvertiert wurden String :

  • AudioChannelMask
  • AudioContentType
  • AudioDevice : hersteller erweiterbar
  • AudioFormat : hersteller erweiterbar
  • AudioGainMode
  • AudioSource
  • AudioStreamType
  • AudioUsage

Passing String ENUM - Werte

Zeichenfolgenwerte werden zum Übertragen von Informationen als Aufzählungswerte über die HAL-Schnittstellengrenze hinweg verwendet. Sowohl der Rahmen und die HAL - Wrapper Verwendung integer ENUM - Werte für die Geschäftslogik der Implementierung und die Umsetzung Ansatz in dargestellt beschäftigen Abbildung 2 .

audio-passing-values

Abbildung 2: Passing string enum - Werte

Als Beispiel, um einen Wert des Audioformattyps vom Framework an den Anbieter zu übergeben:

  1. Der enum - Wert von AudioFormat wird in einem konvertierten string Wert in libaudiohal und an die HAL weitergegeben.
  2. Auf der HAL Seite, den default wrapper die wandelt string auf einen enum - Wert, der auf den Legacy - HAL geben wird.

XML-Schemaänderungen

Das Vorhandensein vollständiger Listen von Enum-Werten im XML-Schema (XSD) ermöglicht eine bessere Validierung der XML-Datei für die Audiorichtlinienkonfiguration durch VTS. In der mit HAL V7 verwendeten Audiorichtlinien-Konfigurationsdatei werden Änderungen vorgenommen, um XSD zu entsprechen.

In V7, ein Standard (space) Zeichen wird abgrenzen Wertelisten in Attributen (wie Abtastraten Kanalmasken und Flags), anstelle der verwendeten , (Komma) und | (vertikaler Balken) Symbole, die in V6 und darunter verwendet werden. Wie im folgenden Beispiel zu sehen ist , ist ein Raum zu begrenzen , um die Liste der Werte für gebrauchte channelMasks :

<profile channelMasks="AUDIO_CHANNEL_OUT_STEREO AUDIO_CHANNEL_OUT_MONO" … />

Um die Symbol Änderungen vornehmen möchten, verwenden Sie eine automatische Konvertierung Skript 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 werden in V7 neu definiert, um doppelte Definitionen zu minimieren. Wiederholte Tupel von Datenelementen werden zu wiederverwendbaren Strukturen gruppiert. Diese Datenstrukturen verwenden die neuesten HIDL-Funktionen wie sichere Vereinigungen.

Zum Beispiel in V6 und unten, ein Tripel <format, sampling rate, channel mask> wird oft in den HIDL Schnittstellen und Typen verwendet. Um diese Redundanz zu entfernen, in V7, der AudioConfigBase Datentyp und andere Datentypen sind wie folgt definiert:

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

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

    verwendet von AudioConfig , AudioOffloadInfo , AudioPortConfig

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

    ersetzt lose Sammlungen in AudioPort/PortConfig

  • AudioPortExtendedInfo := device | mix | session

    ersetzt Gewerkschaften 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 die Wiedergabe und Aufzeichnung von Track-Metadaten können Anbieter ihre eigenen Tags, die verwendet werden, um Attribute zu Audio-E/A-Streams hinzuzufügen, von den Apps an die HAL übergeben.

Vendor-Tags für Playback-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 , die für die Aufzeichnungsspur Metadaten hinzuzufügen.

Namespace für Anbietererweiterungen

Ab HAL V7, Erweiterungen des Herstellers benötigen einen zusätzlichen {vendor} Präfix , das nicht in V6 erforderlich ist. Für den {vendor} Präfix gültig zu sein, muss es drei oder mehr alphanumerische Zeichen.

Verwenden Sie das folgende Format in V7:

VX_ {Verkäufer} _ {Buchstaben / Zahlen / _}

Im Folgenden sind einige Beispiele für gültige V7-Anbietererweiterungen aufgeführt:

  • VX_ GOOGLE _VR
  • VX_ QCI _AMBIENT_MIC

Versionsinformation

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

Android-Version HAL-Version
Android 12 7,0
Android 11 6.0
Android 10 5.0
Android 9 4.0
Android 8 2.0