La fonctionnalité de routage d'appareil audio combiné permet de diffuser du contenu audio en streaming sur plusieurs appareils audio en même temps. Grâce à cette fonctionnalité, les applications privilégiées Sélectionner plusieurs appareils par défaut pour une stratégie particulière via des API système. Les applis peuvent découvrir les fonctionnalités des appareils audio à l'aide des API publiques fournies par cette fonctionnalité. Pour Android 11 et versions antérieures, l'implémentation du framework audio compatibilité limitée avec plusieurs appareils audio du même type (par exemple, 2 casques Bluetooth A2DP) connectés simultanément. Le routage audio par défaut interdisent également aux utilisateurs de sélectionner plusieurs appareils du même type pour une pour un cas d'utilisation donné.
À partir d'Android 12, ces limites sont supprimées afin de permettre de nouveaux cas d'utilisation tels que la diffusion audio ou la multidiffusion vers un groupe. de casques audio BLE ou en sélectionnant plusieurs cartes son USB simultanément. 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 routage vers plusieurs appareils USB à condition que ces appareils utilisent des flux audio différents et prend en charge le noyau et le fournisseur pour connecter plusieurs clés USB appareils en même temps.
Cette page explique comment prendre en charge le streaming audio pour plusieurs appareils audio et comment valider votre implémentation de cette fonctionnalité.
Diffuser du contenu audio sur plusieurs appareils audio
Dans Android 12, deux ensembles d'API sont compatibles avec cette fonctionnalité:
- Pour une stratégie, les API système gèrent plusieurs appareils préférés.
- L'interface HIDL, implémentée par le fournisseur dans le HAL audio, signale les fonctionnalité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
Audio Policy Manager propose des API système pour mieux prendre en charge la diffusion de contenu audio sur plusieurs appareils audio en même temps. Ces API système permettent de définir, d'obtenir et en supprimant plusieurs appareils préférés pour une stratégie donnée. Avant Android 12, cette fonctionnalité n'était prise en charge que pour un seul appareil.
Le gestionnaire de règles audio introduit le concept d'appareils multimédias actifs pour décrivent les appareils les plus susceptibles d'être sélectionnés pour la lecture de contenus multimédias. Quand ? un périphérique détachable est connecté, la sortie audio HAL diffuse des flux qui peuvent être acheminé vers cet appareil peut avoir besoin d’être ouvert et vérifié pour les attributs pris en charge.
Vous devez spécifier un appareil audio à l'ouverture d'un flux de sortie. L'état actif périphérique multimédia est le périphérique utilisé lorsque les flux de sortie sont ouverts dans ce contexte.
La sélection de périphériques multimédias actifs peut varier en fonction des appareils connecté ou déconnecté. Le gestionnaire de règles audio utilise les séries de règles pour choisir les périphériques multimédias actifs:
- Si tous les appareils par défaut pour les contenus multimédias sont disponibles, ils sont tous sélectionnés en tant qu'appareils actifs.
- Sinon, c'est le dernier appareil amovible connecté qui est sélectionné.
- Si aucun appareil amovible n'est connecté, les règles audio par défaut pour choisir les périphériques de sortie sont appliqués pour choisir les périphériques actifs.
Un flux de sortie doit répondre aux critères suivants pour être rouvert et acheminé aux appareils actifs afin que la meilleure configuration soit choisie pour la lecture:
- 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 acheminé vers des appareils actifs.
Pour appliquer un nouvel appareil sélectionné, le gestionnaire de règles audio se ferme et rouvre un flux de sortie lors de la connexion de l'appareil si le flux de sortie est inactif ; ou reporte cette opération lorsque le flux de sortie est mis en veille.
Audio Policy Manager propose la liste suivante d'API système(telles que définies dans
AudioManager.java
):
setPreferredDeviceForStrategy
Définit l'appareil par défaut pour le routage audio pour une stratégie donnée. Remarque que l'appareil peut ne pas être disponible au moment où l'appareil par défaut est définie, mais elle est utilisée une fois qu'elle est disponible.
removePreferredDeviceForStrategy
Supprime le ou les appareils audio par défaut précédemment définis avec
setPreferredDeviceForStrategy
ousetPreferredDevicesForStrategy
.getPreferredDeviceForStrategy
Affiche l'appareil par défaut pour une stratégie audio précédemment définie avec
setPreferredDeviceForStrategy
ousetPreferredDevicesForStrategy
.setPreferredDevicesForStrategy
Définit les appareils préférés pour une stratégie donnée.
getPreferredDevicesForStrategy
Affiche les appareils préférés pour une stratégie audio précédemment définie avec
setPreferredDeviceForStrategy
ousetPreferredDevicesForStrategy
.OnPreferredDevicesForStrategyChangedListener
Définit une interface de notification des modifications de l'audio préféré. qui sont définis pour une stratégie audio donnée.
addOnPreferredDevicesForStrategyChangedListener
Ajoute un écouteur pour être averti des modifications apportées au contenu audio privilégié pour la stratégie appareil.
removeOnPreferredDevicesForStrategyChangedListener
Supprime un écouteur de modifications précédemment ajouté à la stratégie à privilégier appareil audio.
Signaler les fonctionnalités de l'appareil
Dans le cadre de la mise en œuvre de l'HAL audio, les fournisseurs mettent en œuvre les API compatibles signaler les fonctionnalités de l'appareil. Cette section décrit les types de données et les méthodes utilisé pour signaler les fonctionnalités de l'appareil et listant certaines modifications apportées aux fichiers audio HIDL HAL V7 pour prendre en charge plusieurs appareils.
Types de données
Dans les fichiers audio HIDL HAL V7, les fonctionnalités de l'appareil sont signalées à l'aide du AudioProfile
et AudioTransport
. La structure AudioTransport
décrit
d'un port audio avec AudioProfile
pour les formats audio connus, ou avec
descripteurs matériels bruts pour les formats inconnus de la plate-forme. La
La structure AudioProfile
contient le format audio et les taux d'échantillonnage acceptés.
par le profil et la liste des masques de chaîne, comme illustré dans le code suivant :
à partir 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 les fichiers audio HIDL HAL V7, le type de données AudioPort
est défini avec la
les structures AudioTransport
et AudioProfile
pour décrire
des fonctionnalités.
Méthodes HAL audio
Le gestionnaire des règles audio utilise les méthodes suivantes pour interroger les données fonctionnalités:
getParameters:
Méthode générique pour récupérer le paramètre spécifique au fournisseur telles que les formats audio acceptés et leurs taux d'échantillonnage respectifs.getAudioPort:
Renvoie la liste des attributs acceptés (comme l'échantillonnage les taux, les formats, les masques de canal, les contrôleurs de gain) pour un port audio donné.
Le code suivant issu de IDevice.hal
affiche 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 un nouveau
structure appelée audio_port_v7
. Consultez le code source.
pour en savoir plus.
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 fonctionnalités des appareils à l'aide de la
Structure de audio_port_v7
.
Le code suivant issu de audio.h
affiche 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 insérées dans la nouvelle
Format AudioPort
lorsque l'ancienne version de l'API est antérieure à la version 3.2 et que le HAL HIDL
est la version 7 ou une version ultérieure. Dans ce cas, tous les taux d'échantillonnage et canaux
les masques de get_audio_port
sont supposés être pris en charge pour tous les
ce qui permet d'établir un mappage simple entre les valeurs get_audio_port
et les
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és dans les sections précédentes. Reportez-vous à ces méthodes pour obtenir des exemples la mise en œuvre et l'utilisation de ces API.
Voici un exemple d'utilisation de setPreferredDevicesForStrategy
.
getPreferredDevicesForStrategy
, removePreferredDeviceForStrategy
et
Les API système OnPreferredDevicesForStrategyChangedListener
se trouvent
PreferredDeviceRoutingTest
, qui se trouve dans GTS.
Pour voir un exemple d'utilisation de la nouvelle structure dans AudioDeviceInfo
, consultez la
Méthode AudioManagerTest#testGetDevices
située dans CTS.
Vous trouverez un exemple d'implémentation de get_audio_port_v7
dans
audio_hal.c
et comment les capacités sont interrogées pour plusieurs appareils.
Validation
Cette section fournit des informations sur CTS. et la validation GTS (Google Mobile Services Test Suite) d'Audio Manager.
Tests CTS
Les tests CTS se trouvent dans la région suivante : android.media.cts.AudioManagerTest
.
Voici la liste des tests Audio Manager disponibles:
AudioManagerTest#testGetDevices
Vérifie les fonctionnalités précises de l'appareil audio. Elle vérifie également que les profils audio renvoyés dans la structure
AudioDeviceInfo
conservent contenus de l'ancien format de tableau aplati, mais qui se trouvent dans le nouveau FormatAudioProfile
.AudioManagerTest#testPreferredDevicesForStrategy
etAudioManagerTest#testPreferredDeviceForCapturePreset
Vérifiez que les appareils par défaut pour la stratégie et la capture des préréglages Les tests de l'API se sont déroulés avec succès.
Tests GTS
Les tests GTS se trouvent dans le pays suivant : 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 des préréglages
fonctionnent correctement, exécutez les tests AudioServiceHostTest#testPreferredDeviceRouting
et AudioServiceHostTest#testPreferredDeviceRoutingForCapturePreset
.