Limite de type d'appareil

Dans l'audio Android, audio_devices_t est utilisé pour représenter le type de périphérique audio. Il est largement utilisé dans le code source audio comme champ de bits pour filtrer ou sélectionner un ou plusieurs périphériques spécifiés. Avant Android 11, il y avait une limite de 30 types de périphériques d'entrée/sortie audio et aucun emplacement disponible 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. Lors de l'ajout de nouveaux types de périphériques audio, leurs valeurs sont é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 comme masques de bits.

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

Pour représenter plusieurs types de périphériques 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 chez le fournisseur. Pour représenter plusieurs types de périphériques audio en code C, un tableau ou une liste de audio_devices_t peut être utilisé.

Pour vérifier si un seul type de périphérique appartient à une catégorie spécifiée, 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 ) areAllOfSameDeviceType (DeviceTypeSet, std::function ) dans AudioContainers.h pour vérifier si tous les types de périphériques audio donnés sont du même type.

Mise en œuvre

Les OEM doivent supprimer la représentation du champ binaire du type de périphérique audio de l’implémentation audio HAL.

1. Supprimez tout le stockage des 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 sur les bits pour les comparaisons de types de périphériques.

   Avant Android 11, les types de périphériques audio peuvent être utilisés comme champ de bits. Dans ce cas, il est courant d'utiliser des opérations sur bits pour comparer les types de périphériques. 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 les fonctions d’assistance comme alternative. S'il existe un seul type de périphérique audio, utilisez la comparaison directe pour comparer les deux valeurs. Pour vérifier si un type de périphérique audio appartient à une catégorie spécifiée, utilisez les fonctions d'assistance dans /system/media/audio/include/system/audio.h . Par exemple, audio_is_output_device(audio_devices_t device) .

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

   Il existe des valeurs prédéfinies pour les groupes de types de périphériques 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. Il existe de nouveaux groupes de types de périphériques audio définis dans audio-base-utils.h , qui sont des tableaux de types de périphériques 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 de périphériques audio comme champ de bits. Des résultats inattendus peuvent donc se produire si de nouveaux types de périphériques audio énumérés sont ajoutés.

   Actuellement, deux types de patchs audio sont requis :

   • Mixez les patchs de l'appareil, pour la lecture
   • Appareil pour mixer des patchs, pour l'enregistrement

   Dans les mises à jour ultérieures, des correctifs supplémentaires peuvent être requis d’un appareil à l’autre.

   Lors de la création d'un patch audio, si le handle de patch n'est pas spécifié, le HAL audio est requis pour générer un handle de patch unique qui peut identifier le patch audio. Sinon, le HAL audio doit utiliser le handle de patch audio donné pour mettre à jour le patch audio.

   Si vous utilisez un HAL audio hérité et le wrapper AOSP HIDL, le HAL audio hérité doit définir la version principale de HAL sur 3.0.

   Pour activer la fonctionnalité de patch audio, le HAL audio doit définir la version majeure de HAL sur 3.0 ou supérieure. Reportez-vous à Device::supportsAudioPatches() dans l'implémentation HIDL par défaut pour plus d'informations, qui peuvent également être trouvées sur audio HAL pour Cuttlefish.

Personnalisation

Il n'est pas possible de désactiver la fonctionnalité ou d'annuler la refactorisation du périphérique audio dans le cadre qui permet d'ajouter des types de périphériques audio.

Tous les types de périphériques audio ajoutés permettent de représenter un type de périphérique avec un seul jeu de bits, de sorte que les implémentations HAL actuelles fonctionnent 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 audio HAL et passer à HIDL version 6.0 ou supé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 set_parameters pour acheminer le flux peut entraîner des résultats inattendus lorsque de nouveaux types de périphériques audio sont ajoutés.

Validation

Le travail requis pour les OEM consiste à mettre à jour leurs implémentations HAL. VTS pour audio HAL peut être utilisé pour valider si la mise en œuvre fonctionne comme prévu. Tous les tests se trouvent dans les fichiers VTS .