La función de enrutamiento combinado de dispositivos de audio agrega soporte para transmitir audio a múltiples dispositivos de audio simultáneamente. Al utilizar esta función, las aplicaciones privilegiadas pueden seleccionar varios dispositivos preferidos para una estrategia particular mediante las API del sistema. Las aplicaciones pueden descubrir capacidades de dispositivos de audio con mayor precisión mediante el uso de las API públicas proporcionadas por esta función. Para las versiones 11 y anteriores de Android, la implementación del marco de audio tiene soporte limitado para múltiples dispositivos de audio del mismo tipo (por ejemplo, 2 auriculares Bluetooth A2DP) conectados simultáneamente. Las reglas de enrutamiento de audio predeterminadas tampoco permiten a los usuarios seleccionar varios dispositivos del mismo tipo para un caso de uso determinado.
A partir de Android 12, estas limitaciones se eliminan para permitir nuevos casos de uso como transmisión de audio, multidifusión a un grupo de auriculares de audio BLE o selección de varias tarjetas de sonido USB simultáneamente. No se admite el enrutamiento a varios dispositivos USB simultáneamente.
A partir de Android 14, el marco USB admite el enrutamiento a múltiples dispositivos USB siempre que los dispositivos USB sean de diferentes tipos de dispositivos de audio y haya soporte de kernel y proveedor para conectar múltiples dispositivos USB simultáneamente.
Esta página cubre cómo implementar la compatibilidad con la transmisión de audio a múltiples dispositivos de audio y cómo validar la implementación de esta función.
Admite transmisión de audio a múltiples dispositivos de audio
Hay dos conjuntos de API en Android 12 que admiten esta función:
- Las API del sistema manejan múltiples dispositivos preferidos para una estrategia.
- La interfaz HIDL, implementada por el proveedor como parte del audio HAL, informa las capacidades del dispositivo.
Las siguientes secciones analizan cada una de estas API con más detalle.
Manejar múltiples dispositivos preferidos para una estrategia
Audio Policy Manager ofrece API del sistema para admitir mejor la transmisión de audio a varios dispositivos de audio simultáneamente. Estas API del sistema permiten configurar, obtener y eliminar múltiples dispositivos preferidos para una estrategia determinada. Hasta Android 12, esta función solo era compatible con un solo dispositivo.
Audio Policy Manager introduce el concepto de dispositivos multimedia activos para describir los dispositivos que tienen más probabilidades de ser elegidos para la reproducción multimedia. Cuando se conecta un dispositivo desmontable, es posible que sea necesario abrir los flujos de salida de audio HAL que se pueden enrutar a este dispositivo y comprobar los atributos admitidos.
Se debe especificar un dispositivo de audio al abrir una secuencia de salida. El dispositivo de medios activo es el dispositivo que se utiliza cuando se abren flujos de salida en este contexto.
La selección de dispositivos multimedia activos puede cambiar dependiendo de los dispositivos reales conectados o desconectados. Audio Policy Manager utiliza la siguiente serie de reglas para elegir dispositivos multimedia activos:
- Si todos los dispositivos preferidos para medios están disponibles, todos se eligen como dispositivos activos.
- De lo contrario, se elige el último dispositivo extraíble conectado.
- Si no hay dispositivos extraíbles conectados, se aplican las reglas de política de audio predeterminadas para elegir dispositivos de salida para elegir dispositivos activos.
Un flujo de salida debe cumplir los siguientes criterios para volver a abrirse y enrutarse a los dispositivos activos para que se elija la mejor configuración para la reproducción:
- El flujo de salida debe admitir los dispositivos activos.
- El flujo de salida debe admitir perfiles dinámicos.
- El flujo de salida no debe estar enrutado actualmente a dispositivos activos.
Para aplicar una nueva selección de dispositivo, Audio Policy Manager cierra y vuelve a abrir un flujo de salida al conectar el dispositivo si el flujo de salida está inactivo, o lo pospone hasta cuando el flujo de salida se coloca en modo de espera.
Audio Policy Manager ofrece la siguiente lista de API del sistema (como se define en AudioManager.java ):
setPreferredDeviceForStrategyEstablece el dispositivo preferido para el enrutamiento de audio para una estrategia determinada. Tenga en cuenta que es posible que el dispositivo no esté disponible en el momento en que se configura el dispositivo preferido, pero se utiliza una vez que esté disponible.
removePreferredDeviceForStrategyElimina los dispositivos de audio preferidos configurados previamente con
setPreferredDeviceForStrategyosetPreferredDevicesForStrategy.getPreferredDeviceForStrategyDevuelve el dispositivo preferido para una estrategia de audio previamente configurada con
setPreferredDeviceForStrategyosetPreferredDevicesForStrategy.setPreferredDevicesForStrategyEstablece los dispositivos preferidos para una estrategia determinada.
getPreferredDevicesForStrategyDevuelve los dispositivos preferidos para una estrategia de audio previamente configurada con
setPreferredDeviceForStrategyosetPreferredDevicesForStrategy.OnPreferredDevicesForStrategyChangedListenerDefine una interfaz para la notificación de cambios en los dispositivos de audio preferidos que están configurados para una estrategia de audio determinada.
addOnPreferredDevicesForStrategyChangedListenerAgrega un oyente para recibir notificaciones de cambios en el dispositivo de audio preferido de la estrategia.
removeOnPreferredDevicesForStrategyChangedListenerElimina un detector de cambios agregado previamente al dispositivo de audio preferido por la estrategia.
Informar sobre las capacidades del dispositivo
Como parte de la implementación de Audio HAL, los proveedores implementan las API que admiten las capacidades del dispositivo de informes. Esta sección explica los tipos de datos y los métodos utilizados para informar las capacidades del dispositivo y enumera algunos cambios realizados en el audio HIDL HAL V7 para admitir múltiples dispositivos.
Tipos de datos
En audio HIDL HAL V7, las capacidades del dispositivo se informan utilizando las estructuras AudioProfile y AudioTransport . La estructura AudioTransport describe la capacidad de un puerto de audio con AudioProfile para formatos de audio conocidos, o con descriptores de hardware sin formato para formatos que la plataforma no conoce. La estructura AudioProfile contiene el formato de audio, las frecuencias de muestreo admitidas por el perfil y la lista de máscaras de canales, como se muestra en el siguiente bloque de código 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;
};
En audio HIDL HAL V7, el tipo de datos AudioPort se define con las estructuras AudioTransport y AudioProfile para describir las capacidades del dispositivo.
Métodos de audio HAL
Audio Policy Manager utiliza los siguientes métodos para consultar las capacidades del dispositivo:
-
getParameters:un método genérico para recuperar valores de parámetros específicos del proveedor, como los formatos de audio admitidos y sus respectivas frecuencias de muestreo. -
getAudioPort:devuelve la lista de atributos admitidos (como frecuencias de muestreo, formatos, máscaras de canal, controladores de ganancia) para un puerto de audio determinado.
El siguiente código de IDevice.hal muestra la interfaz para el método 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);
Cambios en la API heredada
Para admitir múltiples perfiles de audio, la versión 3.2 de la API heredada agrega una nueva estructura llamada audio_port_v7 . Consulte el código fuente para obtener más detalles.
Debido a la adición de audio_port_v7 , la versión 3.2 de la API heredada agrega una nueva API llamada get_audio_port_v7 para consultar las capacidades de los dispositivos utilizando la estructura audio_port_v7 .
El siguiente código de audio.h muestra la definición de la 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);
Los datos de la API get_audio_port heredada deben completarse en el nuevo formato AudioPort cuando la versión de la API heredada es inferior a 3.2 y la versión HIDL HAL es 7 o superior. En este caso, se supone que todas las frecuencias de muestreo y máscaras de canal informadas de get_audio_port son compatibles con todos los formatos devueltos, lo que permite una asignación sencilla de los valores de get_audio_port a la nueva estructura AudioPort .
Implementaciones de API de ejemplo
Esta sección describe varios conjuntos de pruebas que contienen métodos que utilizan las API tratadas en las secciones anteriores. Consulte estos métodos para ver algunos ejemplos de cómo se implementan y utilizan estas API.
Un ejemplo del uso de las API del setPreferredDevicesForStrategy , getPreferredDevicesForStrategy , removePreferredDeviceForStrategy y OnPreferredDevicesForStrategyChangedListener se encuentra en el método PreferredDeviceRoutingTest , que se encuentra en GTS.
Para ver un ejemplo de la nueva estructura en AudioDeviceInfo en uso, consulte el método AudioManagerTest#testGetDevices que se encuentra en CTS.
Un ejemplo de la implementación de get_audio_port_v7 se encuentra en audio_hal.c y muestra cómo se consultan las capacidades para múltiples dispositivos.
Validación
Esta sección brinda información sobre la validación CTS y GTS (Google Mobile Services Test Suite) del Administrador de audio.
pruebas CTS
Las pruebas CTS se encuentran en android.media.cts.AudioManagerTest .
La siguiente es la lista de pruebas de Audio Manager disponibles:
AudioManagerTest#testGetDevicesVerifica las capacidades precisas del dispositivo de audio. También verifica que los perfiles de audio devueltos en la estructura
AudioDeviceInfoconserven el contenido del formato de matriz aplanado anterior, pero estén en el nuevo formatoAudioProfile.AudioManagerTest#testPreferredDevicesForStrategyyAudioManagerTest#testPreferredDeviceForCapturePresetVerifique que los dispositivos preferidos para las pruebas de API relacionadas con la estrategia y la captura preestablecidas se completen correctamente.
pruebas GTS
Las pruebas GTS se encuentran en com.google.android.gts.audioservice.AudioServiceHostTest .
Para validar si las API de los dispositivos preferidos para estrategia y captura preestablecida funcionan correctamente, ejecute las pruebas AudioServiceHostTest#testPreferredDeviceRouting y AudioServiceHostTest#testPreferredDeviceRoutingForCapturePreset .