La función de enrutamiento combinado de dispositivos de audio agrega compatibilidad para transmitir sonido a varios dispositivos de audio de forma simultánea. Con esta función, las apps privilegiadas pueden seleccionar varios dispositivos preferidos para una estrategia específica por medio de las APIs del sistema. Las apps pueden descubrir las capacidades de los dispositivos de audio con mayor precisión a través de las APIs públicas que proporciona esta función. En las versiones de Android 11 y anteriores, la implementación del framework de audio tiene compatibilidad limitada con varios dispositivos de audio del mismo tipo (por ejemplo, 2 auriculares Bluetooth A2DP) conectados de forma simultánea. Las reglas de enrutamiento de audio predeterminadas tampoco permiten que los usuarios seleccionen varios dispositivos del mismo tipo para un caso de uso determinado.
A partir de Android 12, se quitaron estas limitaciones para permitir nuevos casos de uso, como la transmisión de audio, la transmisión múltiple a un grupo de auriculares de audio BLE o la selección de varias tarjetas de sonido USB de forma simultánea. No se admite el enrutamiento a varios dispositivos USB de forma simultánea.
A partir de Android 14, el framework USB admite el enrutamiento a varios dispositivos USB, siempre que estos sean de diferentes tipos de dispositivos de audio y que haya compatibilidad del kernel y del proveedor para conectar varios dispositivos USB de forma simultánea.
En esta página, se 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.
Admite la transmisión de audio a varios dispositivos de audio
En Android 12, hay dos conjuntos de APIs que admiten esta función:
- Las APIs del sistema controlan varios dispositivos preferidos para una estrategia.
- La interfaz HIDL, implementada por el proveedor como parte de la HAL de audio, informa las capacidades del dispositivo.
En las siguientes secciones, se analizan cada una de estas APIs con más detalle.
Cómo controlar varios dispositivos preferidos para una estrategia
Audio Policy Manager ofrece APIs del sistema para mejorar la compatibilidad con la transmisión de audio a varios dispositivos de audio de forma simultánea. Estas APIs del sistema permiten establecer, obtener y quitar varios dispositivos preferidos para una estrategia determinada. Hasta Android 12, esta función solo era compatible con un dispositivo.
El Audio Policy Manager introduce el concepto de dispositivos multimedia activos para describir los dispositivos que es más probable que se elijan para la reproducción de contenido multimedia. Cuando se conecta un dispositivo desmontable, es posible que se deban abrir y sondear los flujos de salida de la HAL de audio que se pueden enrutar a este dispositivo para detectar los atributos admitidos.
Se debe especificar un dispositivo de audio cuando se abre una transmisión de salida. El dispositivo multimedia activo es el que se usa cuando se abren transmisiones de salida en este contexto.
La selección del dispositivo multimedia activo puede cambiar según los dispositivos reales que se conecten o desconecten. El administrador de políticas de audio usa la siguiente serie de reglas para elegir dispositivos multimedia activos:
- Si todos los dispositivos preferidos para contenido multimedia están disponibles, se eligen como dispositivos activos.
- De lo contrario, se elegirá 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 y seleccionar los dispositivos activos.
Un flujo de salida debe satisfacer los siguientes criterios para que se vuelva a abrir y se enrute 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.
- La transmisión de salida no debe estar enrutada actualmente a dispositivos activos.
Para aplicar una nueva selección de dispositivo, el Audio Policy Manager cierra y vuelve a abrir un flujo de salida cuando se conecta el dispositivo si el flujo de salida está inactivo, o bien lo pospone para cuando el flujo de salida se ponga en modo de espera.
Audio Policy Manager ofrece la siguiente lista de APIs del sistema(como se define en AudioManager.java):
setPreferredDeviceForStrategyEstablece el dispositivo preferido para el enrutamiento de audio de una estrategia determinada. Ten en cuenta que es posible que el dispositivo no esté disponible en el momento en que se configura el dispositivo preferido, pero se usará una vez que esté disponible.
removePreferredDeviceForStrategyQuita los dispositivos de audio preferidos que se configuraron anteriormente con
setPreferredDeviceForStrategyosetPreferredDevicesForStrategy.getPreferredDeviceForStrategyDevuelve el dispositivo preferido para una estrategia de audio establecida anteriormente con
setPreferredDeviceForStrategyosetPreferredDevicesForStrategy.setPreferredDevicesForStrategyEstablece los dispositivos preferidos para una estrategia determinada.
getPreferredDevicesForStrategyDevuelve los dispositivos preferidos para una estrategia de audio establecida anteriormente 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 determinada.
addOnPreferredDevicesForStrategyChangedListenerAgrega un objeto de escucha para recibir notificaciones sobre los cambios en el dispositivo de audio preferido por la estrategia.
removeOnPreferredDevicesForStrategyChangedListenerQuita un objeto de escucha agregado anteriormente para los cambios en el dispositivo de audio preferido por la estrategia.
Crear informes sobre las capacidades del dispositivo
Como parte de la implementación del HAL de audio, los proveedores implementan las APIs que admiten la generación de informes sobre las capacidades del dispositivo. En esta sección, se explican los tipos de datos y los métodos que se usan para informar las capacidades del dispositivo, y se enumeran algunos cambios realizados en el HIDL HAL de audio V7 para admitir varios dispositivos.
Tipos de datos
En la HAL de HIDL de audio V7, las capacidades del dispositivo se informan con 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 tasas 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 la HAL de HIDL de audio V7, el tipo de datos AudioPort se define con las estructuras AudioTransport y AudioProfile para describir las capacidades del dispositivo.
Métodos de HAL de audio
El Administrador de políticas de audio usa los siguientes métodos para consultar las capacidades del dispositivo:
getParameters: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 canales y controladores de ganancia) para un puerto de audio determinado.
El siguiente código de IDevice.hal muestra la interfaz del 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 varios perfiles de audio, la versión 3.2 de la API heredada agrega una nueva estructura llamada audio_port_v7. Consulta el código fuente para obtener más detalles.
Debido a la incorporació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 con la estructura audio_port_v7.
El siguiente código de audio.h muestra la definición de la API de 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 de get_audio_port heredada se deben propagar en el nuevo formato de AudioPort cuando la versión de la API heredada sea inferior a 3.2 y la versión del HAL de HIDL sea 7 o superior. En este caso, se supone que todas las frecuencias de muestreo y las máscaras de canales 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 de AudioPort.
Ejemplos de implementaciones de la API
En esta sección, se describen varios conjuntos de pruebas que contienen métodos que usan las APIs que se abarcan en las secciones anteriores. Consulta estos métodos para ver algunos ejemplos de cómo se implementan y usan estas APIs.
Un ejemplo del uso de las APIs del sistema 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, consulta el método AudioManagerTest#testGetDevices que se encuentra en CTS.
En audio_hal.c, se encuentra un ejemplo de la implementación para get_audio_port_v7, en el que se muestra cómo se consultan las capacidades para varios dispositivos.
Validación
En esta sección, se proporciona información sobre la validación del administrador de audio en las pruebas de CTS y GTS (Google Mobile Services Test Suite).
Pruebas de CTS
Las pruebas de CTS se encuentran en android.media.cts.AudioManagerTest.
A continuación, se muestra la lista de pruebas disponibles de Audio Manager:
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 array aplanado anterior, pero que estén en el nuevo formatoAudioProfile.AudioManagerTest#testPreferredDevicesForStrategyyAudioManagerTest#testPreferredDeviceForCapturePresetVerifica que las pruebas de la API relacionadas con los dispositivos preferidos para la estrategia y los ajustes predeterminados de captura se completen correctamente.
Pruebas de GTS
Las pruebas de GTS se encuentran en com.google.android.gts.audioservice.AudioServiceHostTest.
Para validar si las APIs de los dispositivos preferidos para la estrategia y el ajuste predeterminado de captura funcionan correctamente, ejecuta las pruebas AudioServiceHostTest#testPreferredDeviceRouting y AudioServiceHostTest#testPreferredDeviceRoutingForCapturePreset.