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 el caso de 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 quitan 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 los dispositivos USB sean de diferentes tipos de dispositivos de audio y que haya compatibilidad con el kernel y el proveedor para conectar varios dispositivos USB de forma simultánea.
En esta página, se explica cómo implementar la compatibilidad para transmitir 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
Hay dos conjuntos de APIs en Android 12 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 del HAL de audio, informa las capacidades del dispositivo.
En las siguientes secciones, se analiza cada una de estas APIs con más detalle.
Controla varios dispositivos preferidos para una estrategia
El administrador de políticas de audio 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 configurar, obtener y quitar varios dispositivos preferidos para una estrategia determinada. Hasta Android 12, esta función solo era compatible con un solo dispositivo.
El administrador de políticas de audio introduce el concepto de dispositivos multimedia activos para describir los dispositivos que tienen más probabilidades de seleccionarse para la reproducción de contenido multimedia. Cuando se conecta un dispositivo desmontable, es posible que se deban abrir y probar las transmisiones de salida del HAL de audio que se pueden enrutar a este dispositivo para obtener los atributos compatibles.
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 de dispositivos multimedia activos puede cambiar según los dispositivos conectados o desconectados. 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 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.
Una transmisión de salida debe satisfacer 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:
- La transmisión de salida debe admitir los dispositivos activos.
- La transmisión de salida debe admitir perfiles dinámicos.
- La transmisión de salida no debe enrutarse actualmente a dispositivos activos.
Para aplicar una nueva selección de dispositivos, el administrador de políticas de audio cierra y vuelve a abrir una transmisión de salida cuando se conecta el dispositivo si la transmisión de salida está inactiva o la difiere para cuando la transmisión de salida se pone en modo de espera.
El administrador de políticas de audio ofrece la siguiente lista de APIs del sistema(como se define en
AudioManager.java):
setPreferredDeviceForStrategyEstablece el dispositivo preferido para el enrutamiento de audio para una estrategia determinada. Ten en cuenta que es posible que el dispositivo no esté disponible en el momento en que se establece el dispositivo preferido, pero se usa una vez que está disponible.
removePreferredDeviceForStrategyQuita los dispositivos de audio preferidos que se configuraron anteriormente con
setPreferredDeviceForStrategyosetPreferredDevicesForStrategy.getPreferredDeviceForStrategyMuestra el dispositivo preferido para una estrategia de audio que se configuró anteriormente con
setPreferredDeviceForStrategyosetPreferredDevicesForStrategy.setPreferredDevicesForStrategyEstablece los dispositivos preferidos para una estrategia determinada.
getPreferredDevicesForStrategyMuestra los dispositivos preferidos para una estrategia de audio que se configuró anteriormente con
setPreferredDeviceForStrategyosetPreferredDevicesForStrategy.OnPreferredDevicesForStrategyChangedListenerDefine una interfaz para la notificación de cambios en los dispositivos de audio preferidos que se establecen para una estrategia de audio determinada.
addOnPreferredDevicesForStrategyChangedListenerAgrega un objeto de escucha para recibir notificaciones de los cambios en el dispositivo de audio preferido de la estrategia.
removeOnPreferredDevicesForStrategyChangedListenerQuita un objeto de escucha agregado anteriormente de los cambios en el dispositivo de audio preferido de la estrategia.
Informa 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 de 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 HAL de HIDL de audio V7 para admitir varios dispositivos.
Tipos de datos
En el 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 el 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:Un método genérico para recuperar valores de parámetros específicos del proveedor, como los formatos de audio compatibles y sus respectivas tasas de muestreo.getAudioPort:Muestra la lista de atributos admitidos (como tasas 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 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 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 con la
audio_port_v7 estructura.
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 heredada get_audio_port deben propagarse al nuevo formato AudioPort cuando la versión de la API heredada sea anterior a la 3.2 y la versión del HAL de HIDL sea 7 o posterior. En este caso, se supone que todas las tasas de muestreo y las máscaras de canal informadas de get_audio_port son compatibles con todos los formatos que se muestran, lo que permite una asignación directa de los valores get_audio_port a la nueva estructura AudioPort.
Ejemplos de implementaciones de 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.
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
En esta sección, se proporciona información sobre la validación de CTS y GTS (Google Mobile Services Test Suite) del administrador de audio.
Pruebas de CTS
Las pruebas de CTS se encuentran en android.media.cts.AudioManagerTest.
La siguiente es la lista de pruebas disponibles del administrador de audio:
AudioManagerTest#testGetDevicesVerifica las capacidades precisas del dispositivo de audio. También verifica que los perfiles de audio que se muestran 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 API relacionadas con los dispositivos preferidos para la estrategia y el ajuste preestablecido 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 preestablecido de captura
funcionan correctamente, ejecuta las pruebas AudioServiceHostTest#testPreferredDeviceRouting y AudioServiceHostTest#testPreferredDeviceRoutingForCapturePreset.