HAL audio

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

La couche d'abstraction matérielle (HAL) audio d'Android connecte les API de structure spécifiques à l'audio de niveau supérieur dans android.media aux pilotes audio et au matériel sous-jacents. L'Audio HAL définit l'interface standard dans laquelle les services audio appellent. Il doit être implémenté pour que le matériel audio fonctionne correctement.

Cette page donne un aperçu de la HAL audio et fournit des détails sur son API et les exigences de mise en œuvre.

Interface HAL audio

L'interface audio HAL est définie à l'aide de HIDL dans les fichiers .hal et les schémas XSD pour les fichiers de configuration, illustrés ci-dessous.

audio_hal

Figure 1. Interface HAL audio

Fichiers de configuration

La politique audio et les fichiers de configuration XML des effets audio sont considérés comme faisant partie de l'interface HAL audio. Ces fichiers doivent être conformes à leurs schémas, et la conformité est vérifiée par des tests VTS.

Dans le cadre de l'implémentation de la couche HAL audio, vous devez créer un fichier de configuration de stratégie audio qui décrit la topologie audio. Les capacités HAL audio doivent être déclarées dans le fichier audio_policy_configuration.xml pour que le framework les utilise.

API HAL audio

La couche HAL audio contient les API suivantes :

  • HAL de base
  • Effets HAL
  • HAL commun

Chacune de ces API est décrite dans les sections suivantes.

HAL de base

Le Core HAL est la principale API utilisée par AudioFlinger pour lire l'audio et contrôler le routage audio. Certaines des interfaces clés sont les suivantes :

  • IDeviceFactory.hal est le point d'entrée dans l'API.
  • IDevice.hal et IPrimaryDevice.hal contiennent des méthodes telles que setMasterVolume ou openInputStream .
  • Les flux sont unidirectionnels et sont utilisés par AudioFlinger pour envoyer ou recevoir de l'audio vers et depuis HAL via IStream.hal , IStreamOut.hal et IStreamIn.hal .

Le tableau suivant répertorie l'emplacement des composants Core HAL utiles.

Composant HAL principal Emplacement
Dernière version de l'API /hardware/interfaces/audio/6.0
Types spécifiques à la dernière API Core HAL /hardware/interfaces/audio/6.0/types.hal
Schéma XSD du fichier de configuration de la politique audio /hardware/interfaces/audio/6.0/config/audio_policy_configuration.xsd

L'implémentation par défaut de l'API Core HAL ( /hardware/interfaces/audio/core/all-versions/default/ ) est un wrapper autour de l'implémentation pré-Treble HAL utilisant des bibliothèques partagées héritées . L'implémentation par défaut peut également être considérée comme une référence lors de l'implémentation de nouvelles versions de HAL audio qui interagissent directement avec les pilotes du noyau.

Effets HAL

L'API Effects HAL est utilisée par le framework d'effets pour contrôler les effets audio. Vous pouvez également configurer des effets de prétraitement tels que le contrôle automatique du gain et la suppression du bruit via l'API Effects HAL.

Le tableau suivant répertorie l'emplacement des composants HAL d'effets utiles.

Effets composant HAL Emplacement
Dernière version de l'API /hardware/interfaces/audio/effect/6.0/
Schéma XSD du fichier de configuration des effets /hardware/interfaces/audio/effect/6.0/xml/audio_effects_conf.xsd

Pour plus d'informations, consultez un exemple d'implémentation de l'API Effects HAL ( /hardware/interfaces/audio/effect/all-versions/default/ ) et la section Effets audio .

HAL commun

Common HAL est une bibliothèque de types de données communs utilisés par les API Core et Effects HAL. Il n'a pas d'interfaces et pas de tests VTS associés car il ne définit que des structures de données. L'API HAL commune contient les éléments suivants :

  • Définitions ( /hardware/interfaces/audio/common/6.0/types.hal ) partagées par les API Core et Effect
  • Utilitaires ( /hardware/interfaces/audio/common/all-versions ) utilisés pour faciliter le codage par rapport aux API HIDL pour les implémentations, les clients et les tests

Conditions

Outre la mise en œuvre de la couche HAL audio et la création du fichier de configuration de la politique audio, les exigences HAL suivantes doivent être respectées :

  • Si la capture pour Sound Trigger (capture à partir du tampon DSP de mots clés) est prise en charge par un profil d'entrée, l'implémentation doit prendre en charge le nombre de flux actifs sur ce profil correspondant au nombre de sessions simultanées prises en charge par Sound Trigger HAL.
  • Simultanéité de l'émission d'appels vocaux et de la capture à partir du processeur d'application, comme détaillé sur la page de capture simultanée .

Mises à jour de l'Audio HAL V7

Afin de résoudre les problèmes de rétrocompatibilité, Stable AIDL est obligatoire pour toutes les modifications HAL à partir d'Android 13. Pour prendre en charge et améliorer l'adoption d'AIDL dans Android 13 et versions ultérieures, Audio HAL V7 effectue les opérations suivantes :

  • Unifie les modèles de données utilisés par le framework et HAL.
  • Minimise la duplication entre les types de données HIDL (énumérations) et le schéma XML utilisé pour la configuration de la politique audio.

Plus précisément, des modifications sont apportées dans les domaines suivants dans HAL audio V7 :

Ces modifications sont décrites plus en détail dans leurs sections respectives.

Énumérations

À partir de Audio HAL V7, les types énumérés utilisés dans le fichier de configuration de la politique audio ne sont définis que dans le schéma XSD et non dans le HIDL.

Dans HAL audio V6, les valeurs des types enum (comme AudioFormat ) dans types.hal sont également définies dans le schéma XSD du fichier de configuration de la politique audio, créant une duplication. Pour éviter cela dans V7, les types d'énumération sont changés en string et toutes les valeurs d'énumération possibles sont répertoriées dans le schéma XSD à la place.

Voir la figure 2 pour une comparaison de certaines des modifications apportées au type d'énumération AudioFormat dans V7.

audioformat-change

Figure 2. Comparaison de certaines des modifications apportées à l'énumération AudioFormat

Reportez-vous à la liste suivante pour les types enum qui ont été convertis en String :

  • AudioChannelMask
  • AudioContentType
  • AudioDevice : extensible par le fournisseur
  • AudioFormat : extensible par le fournisseur
  • AudioGainMode
  • AudioSource
  • AudioStreamType
  • AudioUsage

Passer des valeurs d'énumération de chaîne

Les valeurs de chaîne sont utilisées pour transférer des informations sous forme de valeurs d'énumération à travers la limite de l'interface HAL. Le framework et le wrapper HAL utilisent tous deux des valeurs d'énumération entières pour implémenter la logique métier et utilisent l'approche de conversion illustrée à la figure 3 .

audio-passing-values

Figure 3. Transmission de valeurs d'énumération de chaîne

Par exemple, pour transmettre une valeur de type de format audio du framework au fournisseur :

  1. La valeur enum de AudioFormat est convertie en une valeur de chaîne dans libaudiohal et est transmise à HAL.
  2. Du côté HAL, le wrapper par défaut convertit la chaîne en une valeur enum, qui est transmise à l'ancien HAL.

Modifications du schéma XML

Le fait d'avoir des listes complètes de valeurs d'énumération dans la définition de schéma XML (XSD) permet une meilleure validation du fichier XML de configuration de la politique audio par VTS. Des modifications sont apportées au fichier de configuration de la politique audio utilisé avec HAL V7 pour se conformer à XSD.

Dans V7, un caractère standard ␣ (espace) est utilisé pour délimiter les listes de valeurs dans les attributs (comme les taux d'échantillonnage, les masques de canaux et les drapeaux), au lieu des caractères , (virgule) et | (barre verticale) symboles utilisés dans V6 et ci-dessous. Comme on le voit dans l'exemple suivant, un espace est utilisé pour délimiter la liste de valeurs pour channelMasks :

<profile channelMasks="AUDIO_CHANNEL_OUT_STEREO AUDIO_CHANNEL_OUT_MONO" … />

Pour modifier les symboles, utilisez un script de conversion automatique appelé update_audio_policy_config.sh . Consultez la commande suivante pour convertir un fichier de configuration de règles audio V6 en version V7 pour l'appareil Pixel 5 (Redfin) :

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

Types de données

Certaines structures de données sont redéfinies dans la V7 afin de minimiser les définitions en double. Les tuples répétés d'éléments de données sont regroupés dans des structures réutilisables. Ces structures de données utilisent les dernières fonctionnalités HIDL comme les unions sûres.

Par exemple, dans la V6 et les versions antérieures, un triplet de <format, sampling rate, channel mask> est souvent utilisé dans les interfaces et les types HIDL. Pour supprimer cette redondance, dans V7, le type de données AudioConfigBase et les autres types de données sont définis comme suit :

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

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

    utilisé par AudioConfig , AudioOffloadInfo , AudioPortConfig

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

    remplace les collections libres dans AudioPort/PortConfig

  • AudioPortExtendedInfo := device | mix | session

    remplace les unions dans AudioPort/PortConfig

Balises de fournisseur

Outre les types et formats d'appareils, les fournisseurs peuvent ajouter des balises personnalisées pour les métadonnées des pistes audio.

Pour la lecture et l'enregistrement des métadonnées des pistes, les fournisseurs peuvent transmettre leurs propres balises, qui sont utilisées pour ajouter des attributs aux flux d'E/S audio, des applications à HAL.

Les balises de fournisseur pour les métadonnées de la piste de lecture sont ajoutées comme illustré dans l'exemple suivant :

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

La structure RecordTrackMetadata est implémentée de manière similaire en ajoutant des balises spécifiques aux métadonnées de la piste d'enregistrement.

Espace de noms des extensions de fournisseur

À partir de HAL V7, les extensions de fournisseur nécessitent un préfixe {vendor} supplémentaire qui n'est pas requis dans V6. Pour que le préfixe {vendor} soit valide, il doit comporter au moins trois caractères alphanumériques.

Utilisez le format suivant en V7 :

VX_{ vendor }_{ letters/numbers }

Voici quelques exemples d'extensions de fournisseur V7 valides :

  • VX_GOOGLE_VR
  • VX_ QCI _AMBIENT_MIC

Information sur la version

Le tableau suivant répertorie le numéro de version HAL pour chaque version d'Android.

Version Androïd Version HAL
Android 13 7.1
Android 12 7.0
Android 11 6.0
Android 10 5.0
Androïde 9 4.0
Android 8 2.0