Limite du type d'appareil

Dans le système audio Android, audio_devices_t est utilisé pour représenter le type d'appareil audio. Il est largement utilisé dans le code source audio en tant que champ de bits pour filtrer ou sélectionner un ou plusieurs appareils spécifiés. Avant Android 11, il existait une limite de 30 types de périphériques d'entrée/sortie audio, et aucun emplacement libre pour ajouter de nouveaux types de périphériques audio. Nous avons supprimé la limite du nombre de types de périphériques audio pour permettre l'ajout de nouveaux types de périphériques audio.

Pour supprimer la limite du nombre de types de périphériques audio, les types de périphériques audio sont désormais des valeurs énumérées au lieu de masques de bits.

Tous les types de périphériques audio existants sont conservés tels quels. AUDIO_DEVICE_BIT_IN est toujours utilisé pour distinguer les périphériques d'entrée ou de sortie. Lorsque vous ajoutez de nouveaux types de périphériques audio, il s'agit de valeurs énumérées dans les espaces entre les valeurs existantes.

Les OEM ne doivent pas utiliser audio_devices_t comme masque de bits, car cela peut entraîner des résultats inattendus lorsque de nouveaux types de périphériques audio énumérés sont ajoutés.

Exemples et source

Avant Android 11, il existait deux utilisations typiques des types de périphériques audio en tant que masques de bits.

  • Utilisation de la valeur audio_devices_t pour représenter plusieurs appareils audio.
  • Vérifier si la valeur audio_devices_t contient des types de périphériques audio d'une catégorie spécifique.

Pour représenter plusieurs types de périphériques audio, une classe nommée DeviceTypeSet dans /libaudiofoundation/include/media/AudioContainers.h est utilisée. Il s'agit d'un conteneur std::set de audio_devices_t. La classe est déclarée dans la bibliothèque libaudiofoundation disponible auprès du fournisseur. Pour représenter plusieurs types de périphériques audio dans le code C, vous pouvez utiliser un tableau ou une liste de audio_devices_t.

Pour vérifier si un type d'appareil unique appartient à une catégorie spécifique, utilisez les fonctions d'assistance audio_is_.*_device dans /system/media/audio/include/system/audio.h. Dans le cas de plusieurs types de périphériques audio, utilisez les fonctions d'assistance dans libaudiofoundation. Par exemple, utilisez areAllOfSameDeviceType (DeviceTypeSet, std::function) dans AudioContainers.h pour vérifier si tous les types de périphériques audio fournis sont du même type.

Implémentation

Les OEM doivent supprimer la représentation du champ de bits du type d'appareil audio de l'implémentation audio HAL.

  1. Supprimez tout stockage d'appareils sur un champ de bits.

    audio_devices_t ne doit pas être utilisé pour représenter plusieurs types de périphériques audio. Utilisez plutôt une liste ou un vecteur.

  2. Arrêtez d'utiliser les opérations bit à bit pour comparer les types d'appareils.

    Avant Android 11, les types de périphériques audio pouvaient être utilisés comme un champ de bits. Dans ce cas, il est courant d'utiliser des opérations bit à bit pour comparer les types d'appareils. Lorsque de nouveaux types de périphériques audio énumérés sont ajoutés, les opérations sur les bits peuvent entraîner des résultats inattendus. Utilisez plutôt des fonctions d'assistance. S'il n'y a qu'un seul type de périphérique audio, utilisez la comparaison directe pour comparer les deux valeurs. Pour vérifier si un type d'appareil audio appartient à une catégorie spécifique, utilisez les fonctions d'assistance dans /system/media/audio/include/system/audio.h. Exemple : audio_is_output_device(audio_devices_t device).

  3. Arrêtez d'utiliser des valeurs prédéfinies pour les groupes de types d'appareils audio.

    Il existe des valeurs prédéfinies pour les groupes de types d'appareils audio, AUDIO_DEVICE_OUT_ALL, dans system/media/audio/include/system/audio-base-utils.h. Toutes ces valeurs sont réservées, mais peuvent être obsolètes, car elles ne seront pas correctes lorsque de nouveaux types de périphériques audio énumérés seront ajoutés. De nouveaux groupes de types d'appareils audio sont définis dans audio-base-utils.h, qui sont des tableaux de types d'appareils audio, tels que AUDIO_DEVICE_OUT_ALL_ARRAY.

  4. Implémentez les méthodes create_audio_patch() et release_audio_patch() pour le routage au lieu de set_parameters.

    La méthode set_parameters utilise les types d'appareils audio comme un champ de bits. Des résultats inattendus peuvent donc se produire si de nouveaux types d'appareils audio énumérés sont ajoutés.

    Actuellement, deux types de correctifs audio sont requis :

    • Mixer les correctifs de l'appareil pour la lecture
    • Appareil permettant de mixer des patchs, pour l'enregistrement

    Dans les mises à jour ultérieures, des correctifs supplémentaires peuvent être nécessaires pour la communication d'appareil à appareil.

    Lors de la création d'un correctif audio, si le handle du correctif n'est pas spécifié, le HAL audio est tenu de générer un handle de correctif unique permettant d'identifier le correctif audio. Sinon, le HAL audio doit utiliser le handle de correctif audio fourni pour mettre à jour le correctif audio.

    Si vous utilisez un ancien HAL audio et le wrapper HIDL AOSP, l'ancien HAL audio doit définir la version majeure du HAL sur 3.0.

    Pour activer la fonctionnalité de correctif audio, la HAL audio doit définir la version HAL principale sur 3.0 ou une version ultérieure. Pour en savoir plus, consultez Device::supportsAudioPatches() dans l' implémentation HIDL par défaut, qui est également disponible sur le HAL audio pour Cuttlefish.

Personnalisation

Il n'est pas possible de désactiver la fonctionnalité ni d'annuler la refactorisation de l'appareil audio dans le framework qui permet d'ajouter des types d'appareils audio.

Tous les types d'appareils audio ajoutés permettent de représenter un type d'appareil avec un seul bit défini. Les implémentations HAL actuelles fonctionnent donc toujours.

Si de nouveaux types de périphériques audio sont ajoutés et que les OEM souhaitent les utiliser, ils doivent mettre à niveau leur implémentation HAL audio et passer à la version HIDL 6.0 ou ultérieure. Il est obligatoire de mettre à niveau la version majeure de HAL vers la version 3.0 et d'implémenter les méthodes create_audio_patch et release_audio_patch, car l'utilisation de set_parameters pour router le flux peut entraîner des résultats inattendus lorsque de nouveaux types de périphériques audio sont ajoutés.

Validation

Les OEM doivent mettre à jour leurs implémentations HAL. VTS pour le HAL audio peut être utilisé pour vérifier si l'implémentation fonctionne comme prévu. Tous les tests sont disponibles dans les fichiers VTS.