Routage combiné des appareils audio

La fonctionnalité de routage des appareils audio combinés permet de diffuser du contenu audio en streaming vers plusieurs appareils audio simultanément. Grâce à cette fonctionnalité, les applications privilégiées peuvent sélectionner plusieurs appareils préférés pour une stratégie spécifique à l'aide des API système. Les applications peuvent découvrir les fonctionnalités des appareils audio plus précisément en utilisant les API publiques fournies par cette fonctionnalité. Pour les versions d'Android 11 et antérieures, l'implémentation du framework audio offre une compatibilité limitée avec plusieurs appareils audio du même type (par exemple, deux casques Bluetooth A2DP) connectés simultanément. Les règles de routage audio par défaut n'autorisent pas non plus les utilisateurs à sélectionner plusieurs appareils du même type pour un cas d'utilisation donné.

À partir d'Android 12, ces limites sont supprimées afin de permettre de nouveaux cas d'utilisation, comme la diffusion audio, le multicast vers un groupe de casques audio BLE ou la sélection simultanée de plusieurs cartes son USB. Le routage vers plusieurs périphériques USB simultanément n'est pas pris en charge.

À partir d'Android 14, le framework USB permet le routage vers plusieurs appareils USB à condition qu'ils soient de types différents et qu'il existe une compatibilité avec le noyau et le fournisseur pour connecter plusieurs appareils USB simultanément.

Cette page explique comment implémenter la prise en charge du streaming audio vers plusieurs appareils audio et comment valider l'implémentation de cette fonctionnalité.

Prise en charge du streaming audio sur plusieurs appareils audio

Android 12 propose deux ensembles d'API compatibles avec cette fonctionnalité :

  • Les API système gèrent plusieurs appareils préférés pour une stratégie.
  • L'interface HIDL, implémentée par le fournisseur dans le cadre de l'HAL audio, indique les capacités de l'appareil.

Les sections suivantes décrivent chacune de ces API plus en détail.

Gérer plusieurs appareils préférés pour une stratégie

L'Audio Policy Manager propose des API système pour mieux prendre en charge le streaming audio vers plusieurs appareils audio simultanément. Ces API système permettent de définir, d'obtenir et de supprimer plusieurs appareils préférés pour une stratégie donnée. Jusqu'à Android 12, cette fonctionnalité n'était disponible que pour un seul appareil.

L'Audio Policy Manager introduit le concept d'appareils multimédias actifs pour décrire les appareils les plus susceptibles d'être choisis pour la lecture de contenus multimédias. Lorsqu'un appareil détachable est connecté, les flux de sortie HAL audio qui peuvent être routés vers cet appareil peuvent devoir être ouverts et sondés pour les attributs compatibles.

Un périphérique audio doit être spécifié lors de l'ouverture d'un flux de sortie. Le périphérique multimédia actif est celui utilisé lorsque des flux de sortie sont ouverts dans ce contexte.

La sélection de l'appareil multimédia actif peut changer en fonction des appareils réellement connectés ou déconnectés. L'Audio Policy Manager utilise les séries de règles suivantes pour choisir les appareils multimédias actifs :

  1. Si tous les appareils préférés pour le contenu multimédia sont disponibles, ils sont tous choisis comme appareils actifs.
  2. Sinon, le dernier appareil amovible connecté est sélectionné.
  3. Si aucun périphérique amovible n'est connecté, les règles de la stratégie audio par défaut pour le choix des périphériques de sortie sont appliquées pour choisir les périphériques actifs.

Pour qu'un flux de sortie puisse être rouvert et redirigé vers les appareils actifs afin que la meilleure configuration soit sélectionnée pour la lecture, il doit répondre aux critères suivants :

  • Le flux de sortie doit être compatible avec les appareils actifs.
  • Le flux de sortie doit être compatible avec les profils dynamiques.
  • Le flux de sortie ne doit pas être actuellement routé vers des appareils actifs.

Pour appliquer une nouvelle sélection d'appareil, l'Audio Policy Manager ferme et rouvre un flux de sortie lors de la connexion d'un appareil si le flux de sortie est inactif, ou le reporte lorsque le flux de sortie est mis en veille.

Le Gestionnaire de règles audio propose la liste suivante d'API système(telles que définies dans AudioManager.java) :

  • setPreferredDeviceForStrategy

    Définit l'appareil préféré pour le routage audio d'une stratégie donnée. Notez que l'appareil peut ne pas être disponible au moment où l'appareil préféré est défini, mais qu'il est utilisé une fois disponible.

  • removePreferredDeviceForStrategy

    Supprime le ou les appareils audio préférés précédemment définis avec setPreferredDeviceForStrategy ou setPreferredDevicesForStrategy.

  • getPreferredDeviceForStrategy

    Renvoie l'appareil préféré pour une stratégie audio précédemment définie avec setPreferredDeviceForStrategy ou setPreferredDevicesForStrategy.

  • setPreferredDevicesForStrategy

    Définit les appareils préférés pour une stratégie donnée.

  • getPreferredDevicesForStrategy

    Renvoie les appareils préférés pour une stratégie audio précédemment définie avec setPreferredDeviceForStrategy ou setPreferredDevicesForStrategy.

  • OnPreferredDevicesForStrategyChangedListener

    Définit une interface pour la notification des modifications apportées aux appareils audio préférés définis pour une stratégie audio donnée.

  • addOnPreferredDevicesForStrategyChangedListener

    Ajoute un écouteur pour être averti des modifications apportées au périphérique audio préféré de la stratégie.

  • removeOnPreferredDevicesForStrategyChangedListener

    Supprime un écouteur précédemment ajouté pour les modifications apportées au périphérique audio préféré de la stratégie.

Indiquer les fonctionnalités de l'appareil

Dans le cadre de l'implémentation de l'Audio HAL, les fournisseurs implémentent les API qui permettent de signaler les capacités de l'appareil. Cette section explique les types de données et les méthodes utilisées pour signaler les capacités des appareils. Elle liste également certaines modifications apportées à la HAL HIDL audio V7 pour prendre en charge plusieurs appareils.

Types de données

Dans l'audio HIDL HAL V7, les capacités de l'appareil sont signalées à l'aide des structures AudioProfile et AudioTransport. La structure AudioTransport décrit la capacité d'un port audio avec AudioProfile pour les formats audio connus ou avec des descripteurs matériels bruts pour les formats inconnus de la plate-forme. La structure AudioProfile contient le format audio, les taux d'échantillonnage acceptés par le profil et la liste des masques de canal, comme indiqué dans le bloc de code suivant de types.hal :

/**
* Configurations supported for a certain audio format.
*/
struct AudioProfile {
   AudioFormat format;
   /** List of the sample rates (in Hz) supported by the profile. */
   vec<uint32_t> sampleRates;
   /** List of channel masks supported by the profile. */
   vec<AudioChannelMask> channelMasks;
};

Dans Audio HIDL HAL V7, le type de données AudioPort est défini avec les structures AudioTransport et AudioProfile pour décrire les capacités de l'appareil.

Méthodes Audio HAL

L'Audio Policy Manager utilise les méthodes suivantes pour interroger les capacités de l'appareil :

  • getParameters: Méthode générique permettant de récupérer les valeurs de paramètres spécifiques au fournisseur, tels que les formats audio acceptés et leurs fréquences d'échantillonnage respectives.
  • getAudioPort:Renvoie la liste des attributs acceptés (tels que les taux d'échantillonnage, les formats, les masques de canaux et les contrôleurs de gain) pour un port audio donné.

Le code suivant de IDevice.hal montre l'interface de la méthode getAudioPort :

   /**
    * Returns the list of supported attributes for a given audio port.
    *
    * As input, 'port' contains the information (type, role, address etc...)
    * needed by the HAL to identify the port.
    *
    * As output, 'resultPort' contains possible attributes (sampling rates,
    * formats, channel masks, gain controllers...) for this port.
    *
    * @param port port identifier.
    * @return retval operation completion status.
    * @return resultPort port descriptor with all parameters filled up.
    */
   getAudioPort(AudioPort port)
           generates (Result retval, AudioPort resultPort);

Modifications apportées à l'ancienne API

Pour prendre en charge plusieurs profils audio, la version 3.2 de l'ancienne API ajoute une nouvelle structure appelée audio_port_v7. Pour en savoir plus, consultez le code source.

Avec l'ajout de audio_port_v7, la version 3.2 de l'ancienne API ajoute une nouvelle API appelée get_audio_port_v7 pour interroger les capacités des appareils à l'aide de la structure audio_port_v7.

Le code suivant de audio.h montre la définition de l'API get_audio_port_v7 :

/**
 * Fills the list of supported attributes for a given audio port.
 * As input, "port" contains the information (type, role, address etc...)
 * needed by the HAL to identify the port.
 * As output, "port" contains possible attributes (sampling rates,
 * formats, channel masks, gain controllers...) for this port. The
 * possible attributes are saved as audio profiles, which contains audio
 * format and the supported sampling rates and channel masks.
 */
 int (*get_audio_port_v7)(struct audio_hw_device *dev,
                          struct audio_port_v7 *port);

Les données de l'ancienne API get_audio_port doivent être renseignées au nouveau format AudioPort lorsque l'ancienne version de l'API est inférieure à 3.2 et que la version HIDL HAL est égale ou supérieure à 7. Dans ce cas, tous les taux d'échantillonnage et masques de canal signalés à partir de get_audio_port sont supposés être compatibles avec tous les formats renvoyés, ce qui permet un mappage simple des valeurs get_audio_port vers la nouvelle structure AudioPort.

Exemples d'implémentations d'API

Cette section décrit plusieurs suites de tests contenant des méthodes qui utilisent les API abordées dans les sections précédentes. Consultez ces méthodes pour obtenir des exemples d'implémentation et d'utilisation de ces API.

Un exemple d'utilisation des API système setPreferredDevicesForStrategy, getPreferredDevicesForStrategy, removePreferredDeviceForStrategy et OnPreferredDevicesForStrategyChangedListener se trouve dans la méthode PreferredDeviceRoutingTest, qui se trouve dans GTS.

Pour voir un exemple de la nouvelle structure de AudioDeviceInfo en cours d'utilisation, consultez la méthode AudioManagerTest#testGetDevices située dans CTS.

Un exemple d'implémentation pour get_audio_port_v7 se trouve dans audio_hal.c et montre comment les fonctionnalités sont interrogées pour plusieurs appareils.

Validation

Cette section fournit des informations sur la validation CTS et GTS (Google Mobile Services Test Suite) de l'Audio Manager.

Tests CTS

Les tests CTS se trouvent dans android.media.cts.AudioManagerTest.

Voici la liste des tests Audio Manager disponibles :

  • AudioManagerTest#testGetDevices

    Vérifie les capacités précises de l'appareil audio. Il vérifie également que les profils audio renvoyés dans la structure AudioDeviceInfo conservent le contenu de l'ancien format de tableau aplati, mais qu'ils sont au nouveau format AudioProfile.

  • AudioManagerTest#testPreferredDevicesForStrategy et AudioManagerTest#testPreferredDeviceForCapturePreset

    Vérifiez que les tests d'API liés aux préréglages de stratégie et de capture pour les appareils préférés se terminent correctement.

Tests GTS

Les tests GTS se trouvent dans com.google.android.gts.audioservice.AudioServiceHostTest.

Pour vérifier si les API pour les appareils préférés pour la stratégie et la capture de préréglages fonctionnent correctement, exécutez les tests AudioServiceHostTest#testPreferredDeviceRouting et AudioServiceHostTest#testPreferredDeviceRoutingForCapturePreset.