La fonctionnalité de routage combiné des périphériques audio ajoute la prise en charge du streaming 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 Android 11 et inférieures, l'implémentation du framework audio prend en charge de manière limitée 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'usage comme la diffusion audio, le multicast vers un groupe d'écouteurs 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 prend en charge le routage vers plusieurs périphériques USB à condition que les périphériques USB soient de différents types de périphériques audio et qu'il existe une prise en charge du noyau et du fournisseur pour connecter plusieurs périphériques USB simultanément.
Cette page explique comment implémenter la prise en charge du streaming audio sur plusieurs appareils 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 appareils préférés pour une stratégie.
- L'interface HIDL, implémentée par le fournisseur dans le cadre du HAL audio, rend compte des capacités de l'appareil.
Les sections suivantes traitent de chacune de ces API plus en détail.
Gérer 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 sur 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 prise en charge que pour un seul appareil.
Audio Policy Manager 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 détachable est connecté, les flux de sortie audio HAL pouvant ê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 du périphérique multimédia actif peut changer en fonction des périphériques réellement connectés ou déconnectés. Le gestionnaire de politiques audio utilise la série de règles suivante pour choisir les périphériques multimédias actifs :
- Si tous les appareils préférés pour les médias sont disponibles, ils sont tous choisis comme appareils actifs.
- Sinon, le dernier périphérique amovible connecté est choisi.
- Si aucun périphérique amovible n'est connecté, les règles de 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.
Un flux de sortie doit satisfaire aux critères suivants pour être rouvert et acheminé vers les appareils actifs afin que la meilleure configuration soit sélectionnée pour la lecture :
- Le flux de sortie doit prendre en charge les périphériques 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, Audio Policy Manager ferme et rouvre un flux de sortie lors de la connexion du périphérique si le flux de sortie est inactif, ou le reporte lorsque le flux de sortie est mis en veille.
Audio Policy Manager propose la liste suivante d'API système (telle que définie 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 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 appareils préférés pour une stratégie donnée.
getPreferredDevicesForStrategyRenvoie les appareils préférés pour une stratégie audio précédemment définie avec
setPreferredDeviceForStrategyousetPreferredDevicesForStrategy.OnPreferredDevicesForStrategyChangedListenerDéfinit une interface pour la notification des modifications apportées aux périphériques audio préférés définis pour une stratégie audio donnée.
addOnPreferredDevicesForStrategyChangedListenerAjoute un auditeur pour être informé des modifications apportées au périphérique audio préféré par la stratégie.
removeOnPreferredDevicesForStrategyChangedListenerSupprime un auditeur 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 la mise en œuvre d'Audio HAL, les fournisseurs implémentent les API qui prennent en charge les fonctionnalités des appareils de reporting. Cette section explique les types de données et les méthodes utilisées pour signaler les capacités des appareils et répertorie certaines modifications apportées à l'audio HIDL HAL V7 pour prendre en charge plusieurs appareils.
Types de données
Dans l'audio HIDL HAL V7, les capacités du périphérique 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 plateforme. La structure AudioProfile contient le format audio, les fréquences d'échantillonnage prises en charge 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 du périphérique.
Méthodes audio HAL
Audio Policy Manager utilise les méthodes suivantes pour interroger les capacités du périphérique :
-
getParameters:une méthode générique pour récupérer les 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 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 . 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 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 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, toutes les fréquences d'échantillonnage et masques de canal signalés par get_audio_port sont supposés être pris en charge pour tous les formats renvoyés, permettant 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 couvertes dans les sections précédentes. Reportez-vous à ces méthodes pour obtenir des exemples de la façon dont ces API sont implémentées et utilisées.
Un exemple d’utilisation des API 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 d'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) de Audio Manager.
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
AudioDeviceInfopréservent 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 prédéfinis 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 les préréglages de capture fonctionnent correctement, exécutez les tests AudioServiceHostTest#testPreferredDeviceRouting et AudioServiceHostTest#testPreferredDeviceRoutingForCapturePreset .