Limite du type d'appareil

Dans l'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 était limité à 30 types d'appareils d'entrée/sortie audio, et il n'y avait pas d'emplacements disponibles pour ajouter de nouveaux types d'appareils audio. Nous avons supprimé la limite du nombre de types d'appareils audio pour permettre d'ajouter de nouveaux types d'appareils audio.

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

Tous les types d'appareils 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 des types d'appareils audio, ils sont des 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 d'appareils audio énumérés sont ajoutés.

Exemples et source

Avant Android 11, il existait deux utilisations courantes des types d'appareils audio en tant que masques de bits.

  • Utilisation de la valeur audio_devices_t pour représenter plusieurs appareils audio.
  • Vérifiez si la valeur audio_devices_t contient des types d'appareils audio d'une catégorie spécifiée.

Pour représenter plusieurs types d'appareils audio, une classe nommée DeviceTypeSet dans /libaudiofoundation/include/media/AudioContainers.h est utilisée, qui est 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 d'appareils 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 appartient à une catégorie spécifiée, utilisez les fonctions d'assistance audio_is_.*_device dans /system/media/audio/include/system/audio.h. Pour plusieurs types d'appareils audio, utilisez des fonctions d'assistance dans libaudiofoundation. Par exemple, utilisez areAllOfSameDeviceType (DeviceTypeSet, std::function) dans AudioContainers.h pour vérifier si tous les types d'appareils audio donnés 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 du HAL audio.

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

    audio_devices_t ne doit pas être utilisé pour représenter plusieurs types d'appareils audio. Utilisez plutôt une liste ou un vecteur.

  2. Arrêtez d'utiliser des opérations de bits pour comparer les types d'appareils.

    Avant Android 11, les types d'appareils audio peuvent être utilisés comme champ de bits. Dans ce cas, il est courant d'utiliser des opérations de bits pour les comparaisons de types d'appareils. Lorsque de nouveaux types d'appareils audio énumérés sont ajoutés, les opérations de bits peuvent entraîner des résultats inattendus. Utilisez plutôt des fonctions d'assistance. S'il n'y a qu'un seul type d'appareil audio, utilisez une comparaison directe pour comparer les deux valeurs. Pour vérifier si un type d'appareil audio appartient à une catégorie spécifiée, 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.

    Certaines valeurs prédéfinies sont disponibles 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 elles peuvent être obsolètes, car elles ne seront pas correctes lorsque de nouveaux types d'appareils 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. Par conséquent, des résultats inattendus peuvent se produire si de nouveaux types d'appareils audio énumérés sont ajoutés.

    Actuellement, deux types de correctifs audio sont requis:

    • Mélanger les correctifs de l'appareil pour la lecture
    • Appareil permettant de mixer des patches pour l'enregistrement

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

    Lors de la création d'un patch audio, si le handle de patch n'est pas spécifié, le HAL audio doit générer un handle de patch unique qui peut identifier le patch audio. Sinon, le HAL audio doit utiliser le handle de correctif audio donné 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, le HAL audio doit définir la version majeure du HAL sur 3.0 ou ultérieure. Pour en savoir plus, consultez Device::supportsAudioPatches() dans l' implémentation HIDL par défaut, qui se trouve également dans le HAL audio pour Cuttlefish.

Personnalisation

Il n'est pas possible de désactiver cette fonctionnalité ni de revenir à la refactorisation des appareils 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, de sorte que les implémentations HAL actuelles continuent de fonctionner.

Si de nouveaux types d'appareils audio sont ajoutés et que les OEM souhaitent les utiliser, ils doivent mettre à niveau leur implémentation HAL audio et passer à la version 6.0 ou ultérieure de HIDL. 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 acheminer le flux peut entraîner des résultats inattendus lorsque de nouveaux types d'appareils 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 se trouvent dans les fichiers VTS.