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 aplicaciones con privilegios pueden Seleccionar varios dispositivos preferidos para una estrategia específica mediante las APIs del sistema. Las apps pueden descubrir más las capacidades de los dispositivos de audio con el uso de las APIs públicas proporcionadas por 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 transmisión de audio o multidifusión a un grupo de auriculares BLE Audio o seleccionar varias tarjetas de sonido USB al mismo tiempo. 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 con la transmisión de audio en varios dispositivos de audio y cómo validar tu implementación de esta función.
Compatibilidad con la transmisión de audio a varios dispositivos de audio
Existen 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.
Cómo controlar 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 en describen 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 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 abra una transmisión de salida. Los indicadores El dispositivo de medios es el que se usa cuando las transmisiones de salida se abren 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 elegirá 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:
- La transmisión de salida debe admitir los dispositivos activos.
- La transmisión 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 Reabre una transmisión de salida cuando se conecta el dispositivo si está inactiva. la aplaza para cuando la transmisión de salida se coloca 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 establecidos previamente con
setPreferredDeviceForStrategyosetPreferredDevicesForStrategy.getPreferredDeviceForStrategyMuestra el dispositivo preferido para una estrategia de audio configurada anteriormente 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 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 la HAL de audio, los proveedores implementan las APIs que admiten informes de capacidades de los dispositivos. En esta sección, se explican los tipos de datos y los métodos se usa para informar las capacidades del dispositivo y enumera algunos cambios realizados en la HAL del HIDL de audio 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 la HAL de HIDL V7 de audio, el tipo de datos AudioPort se define con el
Las estructuras AudioTransport y AudioProfile para describir la característica
capacidades de integración.
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 el muestreo). frecuencias, formatos, máscaras de canal 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 un nuevo
estructurada llamada audio_port_v7. Consulta el código fuente para obtener más detalles.
Debido a que se agregó audio_port_v7, la versión 3.2 de la API heredada agrega un
API nueva llamada get_audio_port_v7 para consultar las capacidades de los dispositivos con el
audio_port_v7.
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 de 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 explicaron 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 ofrece información sobre CTS y la validación GTS (conjunto de pruebas de servicios de Google para dispositivos móviles) del Administrador de audio.
Pruebas de CTS
Las pruebas de CTS se encuentran en android.media.cts.AudioManagerTest.
Esta 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 se usan 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.