La fonction de routage de périphérique audio combiné ajoute la prise en charge de la diffusion audio vers plusieurs périphériques 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 particulière au moyen d'API système. Les applications peuvent découvrir plus précisément les capacités des appareils audio en utilisant les API publiques fournies par cette fonctionnalité. Pour les versions 11 et inférieures d'Android, la mise en œuvre de la structure audio a une prise en charge limitée de plusieurs appareils audio du même type (par exemple, 2 casques Bluetooth A2DP) connectés simultanément. Les règles de routage audio par défaut ne permettent pas non plus aux utilisateurs de sélectionner plusieurs appareils du même type pour un cas d'utilisation donné.
À partir d'Android 12, ces limitations sont supprimées afin de permettre de nouveaux cas d'utilisation comme la diffusion audio, la multidiffusion vers un groupe d'écouteurs audio BLE ou l'utilisation simultanée de plusieurs cartes son USB.
Cette page explique comment implémenter la prise en charge du streaming audio sur plusieurs périphériques audio et comment valider votre implémentation de cette fonctionnalité.
Prise en charge du streaming audio sur plusieurs appareils audio
Il existe deux ensembles d'API dans Android 12 qui prennent en charge cette fonctionnalité :
- Les API système gèrent plusieurs périphériques préférés pour une stratégie.
- L'interface HIDL, implémentée par le fournisseur dans le cadre de la HAL audio, signale les capacités de l'appareil.
Les sections suivantes décrivent chacune de ces API plus en détail.
Gestion de plusieurs appareils préférés pour une stratégie
Audio Policy Manager propose des API système pour mieux prendre en charge le streaming audio vers plusieurs périphériques 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 prise en charge que pour un seul appareil.
Le gestionnaire de règles audio introduit le concept de périphériques multimédias actifs pour décrire les périphériques les plus susceptibles d'être sélectionnés pour la lecture multimédia. Lorsqu'un périphérique amovible est connecté, les flux de sortie audio HAL qui peuvent être acheminés vers ce périphérique peuvent devoir être ouverts et sondés pour les attributs pris en charge.
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 le périphérique utilisé lorsque les flux de sortie sont ouverts dans ce contexte.
La sélection de périphérique multimédia actif peut changer en fonction des périphériques réels connectés ou déconnectés. Le gestionnaire de règles audio utilise la série de règles suivante pour choisir les périphériques multimédias actifs :
- Si tous les périphériques préférés pour les médias sont disponibles, ils sont tous choisis comme périphériques actifs.
- Sinon, le dernier périphérique amovible connecté est choisi.
- Si aucun périphérique amovible n'est connecté, les règles de politique audio par défaut pour le choix des périphériques de sortie sont appliquées pour choisir les périphériques actifs.
Un flux de sortie doit répondre aux critères suivants pour être rouvert et acheminé vers les périphériques actifs afin que la meilleure configuration soit sélectionnée pour la lecture :
- Le flux de sortie doit prendre en charge les appareils actifs.
- Le flux de sortie doit prendre en charge les profils dynamiques.
- Le flux de sortie ne doit pas être actuellement acheminé vers des appareils actifs.
Afin d'appliquer une nouvelle sélection de périphérique, le gestionnaire de politique audio ferme et rouvre un flux de sortie lors de la connexion du périphérique si le flux de sortie est inactif, ou le diffère 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 ):
setPreferredDeviceForStrategyDéfinit le périphérique préféré pour le routage audio pour 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 rendu disponible.
removePreferredDeviceForStrategySupprime le ou les périphériques audio préférés précédemment définis avec
setPreferredDeviceForStrategyousetPreferredDevicesForStrategy.getPreferredDeviceForStrategyRenvoie le périphérique préféré pour une stratégie audio précédemment définie avec
setPreferredDeviceForStrategyousetPreferredDevicesForStrategy.setPreferredDevicesForStrategyDéfinit les périphériques préférés pour une stratégie donnée.
getPreferredDevicesForStrategyRenvoie les périphériques préférés pour une stratégie audio précédemment définie avec
setPreferredDeviceForStrategyousetPreferredDevicesForStrategy.OnPreferredDevicesForStrategyChangedListenerDéfinit une interface pour la notification des changements dans les périphériques audio préférés qui sont définis pour une stratégie audio donnée.
addOnPreferredDevicesForStrategyChangedListenerAjoute un écouteur pour être informé des modifications apportées au périphérique audio préféré par la stratégie.
removeOnPreferredDevicesForStrategyChangedListenerSupprime un écouteur précédemment ajouté des modifications apportées au périphérique audio préféré par la stratégie.
Capacités de l'appareil de rapport
Dans le cadre de l'implémentation Audio HAL, les fournisseurs implémentent les API qui prennent en charge les capacités des appareils de génération de rapports. Cette section explique les types de données et les méthodes utilisées pour signaler les capacités des périphériques et répertorie certaines modifications apportées à l'audio HIDL HAL V7 pour prendre en charge plusieurs périphériques.
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 qui ne sont pas connus par la plate-forme. La structure AudioProfile contient le format audio, les taux d'échantillonnage pris en charge par le profil et la liste des masques de canaux, 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 l'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 HAL audio
Le gestionnaire de règles audio utilise les méthodes suivantes pour interroger les capacités de l'appareil :
-
getParameters:une méthode générique pour récupérer des valeurs de paramètres spécifiques au fournisseur, telles que les formats audio pris en charge et leurs taux d'échantillonnage respectifs. -
getAudioPort:renvoie la liste des attributs pris en charge (comme les taux d'échantillonnage, les formats, les masques de canal, les contrôleurs de gain) pour un port audio donné.
Le code suivant de IDevice.hal montre l'interface pour 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 de 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 . Voir le code source pour plus de détails.
En raison de 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 périphériques à 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 dans le nouveau format AudioPort lorsque la version de l'ancienne API est inférieure à 3.2 et que la version HIDL HAL est 7 ou supérieure. Dans ce cas, tous les taux d'échantillonnage et masques de canal signalés de get_audio_port sont supposés être pris en charge pour tous les formats renvoyés, permettant un mappage direct des valeurs get_audio_port à 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 couvertes dans les sections précédentes. Reportez-vous à 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 utilisée dans AudioDeviceInfo , consultez la méthode AudioManagerTest#testGetDevices qui se trouve dans CTS.
Un exemple de l'implémentation de get_audio_port_v7 se trouve dans audio_hal.c et montre comment les capacités sont interrogées pour plusieurs appareils.
Validation
Cette section donne des informations sur la validation CTS et GTS (Google Mobile Services Test Suite) du gestionnaire audio.
Essais CTS
Les tests CTS se trouvent dans android.media.cts.AudioManagerTest .
Voici la liste des tests Audio Manager disponibles :
AudioManagerTest#testGetDevicesVérifie les capacités précises du périphérique audio. Il vérifie également que les profils audio renvoyés dans la structure
AudioDeviceInfoconservent le contenu de l'ancien format de tableau aplati, mais sont au nouveau formatAudioProfile.AudioManagerTest#testPreferredDevicesForStrategyetAudioManagerTest#testPreferredDeviceForCapturePresetVérifiez que les appareils préférés pour la stratégie et les tests d'API liés aux préréglages de capture se terminent avec succès.
Essais GTS
Les tests GTS se trouvent dans com.google.android.gts.audioservice.AudioServiceHostTest .
Pour vérifier si les API des appareils préférés pour la stratégie et le préréglage de capture fonctionnent correctement, exécutez les AudioServiceHostTest#testPreferredDeviceRouting et AudioServiceHostTest#testPreferredDeviceRoutingForCapturePreset .