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. Para Android 11 y versiones 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 simultáneamente. Enrutamiento de audio predeterminado tampoco permiten que los usuarios seleccionen varios dispositivos del mismo tipo para una 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 enrutamiento a varios dispositivos USB siempre que los dispositivos USB sean de diferente audio de dispositivos compatibles. Además, se admiten kernel y proveedores para conectar varios puertos USB al mismo tiempo.
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 en 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, implementada por el proveedor como parte de la HAL de audio informa las capacidades del dispositivo.
En las siguientes secciones, se analiza cada una de estas APIs en más detalle.
Cómo controlar varios dispositivos preferidos para una estrategia
El Administrador de políticas de audio ofrece APIs del sistema para una mejor compatibilidad con la transmisión de audio a varios dispositivos de audio a la vez. Estas APIs del sistema habilitan la configuración, y quitar varios dispositivos preferidos para una estrategia determinada. Hasta que Android 12, esta función 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. Cuándo hay un dispositivo desmontable conectado, la salida de la HAL de audio transmite que se puede enrutados a este dispositivo deban abrirse y sondearse para detectar atributos admitidos.
Se debe especificar un dispositivo de audio cuando se abra una transmisión de salida. Los grupos de El dispositivo de medios es el que se usa cuando las transmisiones de salida se abren en este contexto.
La selección de dispositivos multimedia activos puede cambiar según los dispositivos reales conectadas o desconectadas. El Administrador de políticas de audio utiliza la siguiente serie de reglas para elegir dispositivos multimedia activos:
- Si todos los dispositivos preferidos para contenido multimedia están disponibles, se eligen todos. como dispositivos activos.
- De lo contrario, se elegirá el último dispositivo extraíble conectado.
- Si no hay dispositivos extraíbles conectados, las reglas de la política de audio predeterminadas para elegir dispositivos de salida y así elegir dispositivos activos.
Una transmisión de salida debe cumplir con 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 Reabre una transmisión de salida cuando se conecta el dispositivo si está inactiva. la pospone 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 para una estrategia determinada. Nota que el dispositivo puede no estar disponible en el momento en que el pero se usa cuando están disponibles.
removePreferredDeviceForStrategyQuita 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 el audio preferido. dispositivos configurados para una estrategia de audio determinada.
addOnPreferredDevicesForStrategyChangedListenerAgrega un objeto de escucha para recibir notificaciones sobre los cambios en el audio preferido para la estrategia. dispositivo.
removeOnPreferredDevicesForStrategyChangedListenerQuita un objeto de escucha agregado anteriormente de cambios a la estrategia preferida. dispositivo de audio.
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 HIDL V7 de audio, las capacidades del dispositivo se informan a través del 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. El
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 código
bloqueo 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 la HAL de audio
El Administrador de políticas de audio usa los siguientes métodos para consultar capacidades:
getParameters:Es un método genérico para recuperar 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.
El siguiente código de IDevice.hal
Se 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 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 información.
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 de get_audio_port heredada deben propagarse en la nueva
AudioPort cuando la versión heredada de la API es inferior a 3.2 y la HAL de HIDL
versión 7 o posterior. En este caso, todas las tasas de muestreo y las métricas
se supone que las máscaras de get_audio_port son compatibles con todos los valores
de formato, lo que permite una asignación directa de los valores get_audio_port al
nueva estructura de AudioPort.
Ejemplos de implementaciones 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 obtener algunos ejemplos de cómo se implementan y usan estas APIs.
Un ejemplo del uso de setPreferredDevicesForStrategy:
getPreferredDevicesForStrategy, removePreferredDeviceForStrategy y
Las APIs del sistema de OnPreferredDevicesForStrategyChangedListener se encuentran en
PreferredDeviceRoutingTest, que se encuentra en GTS
Para ver un ejemplo de la nueva estructura de AudioDeviceInfo en uso, consulta la
AudioManagerTest#testGetDevices, que se encuentra en el CTS.
Puedes encontrar un ejemplo de implementación para get_audio_port_v7 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 del 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
AudioDeviceInfoconservan el del formato anterior de array aplanado, pero que están en el nuevoAudioProfile.AudioManagerTest#testPreferredDevicesForStrategyyAudioManagerTest#testPreferredDeviceForCapturePresetVerifica que los dispositivos preferidos para estrategia y captura preestablecidos relacionados Las pruebas de la API se completaron correctamente.
Pruebas 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.