La función de enrutamiento de dispositivos de audio combinados agrega soporte para la transmisión de audio a múltiples dispositivos de audio simultáneamente. Con esta función, las aplicaciones privilegiadas pueden seleccionar múltiples dispositivos preferidos para una estrategia particular a través de las API del sistema. Las aplicaciones pueden descubrir las capacidades de los dispositivos de audio con mayor precisión mediante el uso de las API públicas proporcionadas por esta característica. Para las versiones de Android 11 e inferiores, la implementación del marco de audio tiene compatibilidad limitada con varios 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 la transmisión de audio, la multidifusión a un grupo de auriculares de audio BLE o el uso de varias tarjetas de sonido USB simultáneamente.
Esta página explica cómo implementar la compatibilidad con la transmisión de audio a varios dispositivos de audio y cómo validar la implementación de esta función.
Compatibilidad con la 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 de la HAL de audio, informa las capacidades del dispositivo.
Las siguientes secciones analizan cada una de estas API con más detalle.
Manejo de 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 se admitía en un solo dispositivo.
Audio Policy Manager introduce el concepto de dispositivos de medios activos para describir los dispositivos que es más probable que se elijan para la reproducción de medios. Cuando se conecta un dispositivo desmontable, es posible que los flujos de salida HAL de audio que se pueden enrutar a este dispositivo deban abrirse y probarse en busca de atributos admitidos.
Se debe especificar un dispositivo de audio al abrir un flujo de salida. El dispositivo multimedia activo es el dispositivo que se utiliza cuando se abren flujos de salida en este contexto.
La selección del dispositivo multimedia activo puede cambiar según los dispositivos reales conectados o desconectados. Audio Policy Manager utiliza la siguiente serie de reglas para elegir dispositivos de medios 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, las reglas de política de audio predeterminadas para elegir dispositivos de salida se aplican para elegir dispositivos activos.
Un flujo de salida debe cumplir los siguientes criterios para volver a abrirse y enrutarse a los dispositivos activos, de modo 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 actualmente enrutado a dispositivos activos.
Para aplicar una nueva selección de dispositivo, el Administrador de políticas de audio cierra y vuelve a abrir un flujo de salida al conectar el dispositivo si el flujo de salida está inactivo, o lo pospone para cuando el flujo de salida se pone 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 usa una vez que está disponible.
removePreferredDeviceForStrategyElimina los dispositivos de audio preferidos establecidos previamente con
setPreferredDeviceForStrategyosetPreferredDevicesForStrategy.getPreferredDeviceForStrategyDevuelve el dispositivo preferido para una estrategia de audio configurada previamente con
setPreferredDeviceForStrategyosetPreferredDevicesForStrategy.setPreferredDevicesForStrategyEstablece los dispositivos preferidos para una estrategia determinada.
getPreferredDevicesForStrategyDevuelve los dispositivos preferidos para una estrategia de audio configurada previamente con
setPreferredDeviceForStrategyosetPreferredDevicesForStrategy.OnPreferredDevicesForStrategyChangedListenerDefine una interfaz para la notificación de cambios en los dispositivos de audio preferidos que se configuran para una estrategia de audio dada.
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 de la estrategia.
Capacidades del dispositivo de informes
Como parte de la implementación de Audio HAL, los proveedores implementan las API que admiten las capacidades de los dispositivos de generación 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 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 procesar 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 canal, 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 HAL de audio
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 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 . Ver el código fuente para 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 mediante 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 heredada get_audio_port deben completarse en el nuevo formato AudioPort cuando la versión heredada de la API 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 directa de los valores de get_audio_port a la nueva estructura AudioPort .
Ejemplos de implementaciones de API
Esta sección describe varios conjuntos de pruebas que contienen métodos que usan las API cubiertas 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 es el método PreferredDeviceRoutingTest , que se encuentra en GTS.
Para ver un ejemplo de la nueva estructura en uso en AudioDeviceInfo , 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 de varios 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 de 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 plano más antiguo, pero estén en el nuevo formatoAudioProfile.AudioManagerTest#testPreferredDevicesForStrategyyAudioManagerTest#testPreferredDeviceForCapturePresetVerifique que los dispositivos preferidos para la estrategia y capturen las pruebas de API relacionadas con los ajustes preestablecidos se completen correctamente.
Pruebas GTS
Las pruebas de GTS se encuentran en com.google.android.gts.audioservice.AudioServiceHostTest .
Para validar si las API de los dispositivos preferidos para la estrategia y la captura preestablecida funcionan correctamente, ejecute las AudioServiceHostTest#testPreferredDeviceRouting y AudioServiceHostTest#testPreferredDeviceRoutingForCapturePreset .