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 con privilegios 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 11 y anteriores de Android, 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 predeterminadas de enrutamiento de audio 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 multicast 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 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.
Compatibilidad con 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, que el proveedor implementa 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 admitir mejor 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 presenta el concepto de dispositivos multimedia activos para describir los dispositivos que tienen más probabilidades de elegirse 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 de HAL de audio que se pueden enrutar a este dispositivo para verificar 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 flujos de salida en este contexto.
La selección del dispositivo multimedia activo puede cambiar según los dispositivos que estén 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 el contenido multimedia están disponibles, se elegirán todos 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 predeterminadas de la política de audio para elegir dispositivos de salida y elegir dispositivos activos.
Un flujo 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:
- 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 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 esta está inactiva, o bien la aplaza para cuando 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 de una estrategia determinada. Ten en cuenta que es posible que el dispositivo no esté disponible en el momento en que se configure el dispositivo preferido, pero se usará una vez que esté disponible.
removePreferredDeviceForStrategyQuita los dispositivos de audio preferidos configurados anteriormente con
setPreferredDeviceForStrategyosetPreferredDevicesForStrategy.getPreferredDeviceForStrategyMuestra el dispositivo preferido para una estrategia de audio configurada anteriormente con
setPreferredDeviceForStrategyosetPreferredDevicesForStrategy.setPreferredDevicesForStrategyEstablece los dispositivos preferidos para una estrategia determinada.
getPreferredDevicesForStrategyMuestra los dispositivos preferidos para una estrategia de audio configurada anteriormente con
setPreferredDeviceForStrategyosetPreferredDevicesForStrategy.OnPreferredDevicesForStrategyChangedListenerDefine una interfaz para notificar los 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 de los cambios en el dispositivo de audio preferido por la estrategia.
Informa las capacidades del dispositivo
Como parte de la implementación de HAL de audio, los proveedores implementan las APIs que admiten informar 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 audio HIDL HAL V7 para admitir varios dispositivos.
Tipos de datos
En la HAL de audio HIDL 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 compatibles con 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 el 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 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:Devuelve la lista de atributos admitidos (como tasas de muestreo, formatos, máscaras de canales y controladores de ganancia) para un puerto de audio determinado.
En el siguiente código de IDevice.hal, se 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 API nueva llamada get_audio_port_v7 para consultar las capacidades de los dispositivos con la estructura audio_port_v7.
En el siguiente código de audio.h,
se 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 de get_audio_port se deben propagar al nuevo formato AudioPort cuando la versión de la API heredada es inferior a 3.2 y la versión de HAL de HIDL es 7 o superior. En este caso, se supone que todas las tasas de muestreo y máscaras de canales informadas de get_audio_port son compatibles con todos los formatos que se muestran, lo que permite una asignación directa de los valores de get_audio_port a la nueva estructura AudioPort.
Implementaciones de ejemplo de la API
En esta sección, se describen varios paquetes de pruebas que contienen métodos que usan las APIs que se analizaron 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 para varios dispositivos.
Validación
En esta sección, se proporciona información sobre la validación del Administrador de audio en CTS y GTS (Google Mobile Services Test Suite).
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
AudioDeviceInfopreserven el contenido del formato de array aplanado anterior, pero que estén en el nuevo formatoAudioProfile.AudioManagerTest#testPreferredDevicesForStrategyyAudioManagerTest#testPreferredDeviceForCapturePresetVerifica que los dispositivos preferidos para la estrategia y la captura de pruebas de API relacionadas con los parámetros preestablecidos 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 la captura de ajustes predeterminados funcionan correctamente, ejecuta las pruebas AudioServiceHostTest#testPreferredDeviceRouting y AudioServiceHostTest#testPreferredDeviceRoutingForCapturePreset.