Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Enrutamiento combinado de dispositivos de audio

La función de enrutamiento de dispositivo de audio combinado agrega soporte para la transmisión de audio a múltiples dispositivos de audio simultáneamente. Con esta función, las aplicaciones privilegiadas pueden seleccionar varios dispositivos preferidos para una determinada estrategia a modo de API del sistema. Las aplicaciones pueden descubrir las capacidades de los dispositivos de audio con mayor precisión mediante el uso de las API públicas proporcionadas por esta función. Para las versiones de Android 11 y anteriores, la implementación del marco de audio tiene soporte limitado para varios dispositivos de audio del mismo tipo (por ejemplo, 2 auriculares Bluetooth A2DP) conectados simultáneamente. Las reglas de enrutamiento de audio predeterminadas tampoco permiten a los usuarios seleccionar varios dispositivos del mismo tipo para un caso de uso determinado.

A partir de Android 12, estas limitaciones se eliminan para permitir nuevos casos de uso como la transmisión de audio, la multidifusión a un grupo de auriculares de audio BLE o el uso de varias tarjetas de sonido USB simultáneamente.

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 transmisión de audio a múltiples dispositivos de audio

Hay dos conjuntos de API en Android 12 que admiten esta función:

  • Las API del sistema manejan múltiples dispositivos preferidos para una estrategia.
  • La interfaz HIDL, implementada por el proveedor como parte de la HAL de audio, informa las capacidades del dispositivo.

Las siguientes secciones tratan cada una de estas API con más detalle.

Manejo de múltiples dispositivos preferidos para una estrategia

Audio Policy Manager ofrece API del sistema para admitir mejor la transmisión de audio a varios dispositivos de audio simultáneamente. Estas API del sistema de ajuste de habilitación, la obtención y la eliminación de múltiples dispositivos preferidos para una estrategia dada. Hasta Android 12, esta función solo era compatible con un solo dispositivo.

El Administrador de directivas de audio introduce el concepto de dispositivos de medios activos para describir los dispositivos que tienen más probabilidades de ser recogidos para la reproducción de los medios de comunicación. Cuando se conecta un dispositivo desmontable, es posible que las secuencias de salida de audio HAL que se pueden enrutar a este dispositivo deban abrirse y probarse en busca de atributos admitidos.

Se debe especificar un dispositivo de audio al abrir un flujo de salida. El dispositivo de medios activo es el dispositivo que se utiliza cuando se abren flujos de salida en este contexto.

La selección del dispositivo de medios activo puede cambiar según los dispositivos reales conectados o desconectados. Audio Policy Manager utiliza la siguiente serie de reglas para elegir dispositivos multimedia activos:

  1. Si todos los dispositivos preferidos para los medios están disponibles, todos se eligen como dispositivos activos.
  2. De lo contrario, se elige el último dispositivo extraíble conectado.
  3. Si no hay dispositivos extraíbles conectados, las reglas de política de audio predeterminadas para elegir los dispositivos de salida se aplican para elegir los dispositivos activos.

Un flujo de salida debe satisfacer los siguientes criterios para volver a abrirse y enrutarse a los dispositivos activos para 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 enrutarse actualmente a dispositivos activos.

Para aplicar una nueva selección de dispositivo, Audio Policy Manager cierra y vuelve a abrir un flujo de salida al conectar el dispositivo si el flujo de salida está inactivo, o lo pospone para cuando el flujo de salida se coloca en modo de espera.

El Administrador de directivas de audio ofrece la siguiente lista de las API del sistema (como se define en AudioManager.java ):

  • setPreferredDeviceForStrategy

    Establece el dispositivo preferido para el enrutamiento de audio para una estrategia determinada. Tenga en cuenta que es posible que el dispositivo no esté disponible en el momento en que se configura el dispositivo preferido, pero se utiliza una vez que está disponible.

  • removePreferredDeviceForStrategy

    Elimina el dispositivo de audio preferido (s) previamente establecido con setPreferredDeviceForStrategy o setPreferredDevicesForStrategy .

  • getPreferredDeviceForStrategy

    Devuelve el dispositivo preferido para una estrategia de audio previamente establecido con setPreferredDeviceForStrategy o setPreferredDevicesForStrategy .

  • setPreferredDevicesForStrategy

    Establece los dispositivos preferidos para una estrategia determinada.

  • getPreferredDevicesForStrategy

    Devuelve los dispositivos preferidos para una estrategia de audio previamente establecido con setPreferredDeviceForStrategy o setPreferredDevicesForStrategy .

  • OnPreferredDevicesForStrategyChangedListener

    Define una interfaz para la notificación de cambios en los dispositivos de audio preferidos que están configurados para una estrategia de audio determinada.

  • addOnPreferredDevicesForStrategyChangedListener

    Agrega un oyente para recibir notificaciones de cambios en el dispositivo de audio preferido por la estrategia.

  • removeOnPreferredDevicesForStrategyChangedListener

    Elimina un oyente de cambios previamente agregado al dispositivo de audio preferido por la estrategia.

Capacidades del dispositivo de informes

Como parte de la implementación de Audio HAL, los proveedores implementan las API que admiten las capacidades de los dispositivos de informes. Esta sección explica los tipos de datos y los métodos utilizados para informar las capacidades del dispositivo y enumera algunos cambios realizados en el audio HIDL HAL V7 para admitir varios dispositivos.

Tipos de datos

En HIDL de audio HAL V7 se reportan las capacidades del dispositivo utilizando las AudioProfile y AudioTransport estructuras. El AudioTransport estructura describe la capacidad de un puerto de audio con AudioProfile de formatos de audio conocidos, o con descriptores de hardware primas para formatos que no son conocidos por la plataforma. El AudioProfile estructura contiene el formato de audio, las frecuencias de muestreo soportados 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 audio HIDL HAL V7, la AudioPort tipo de datos se define con las AudioTransport y AudioProfile estructuras para describir las capacidades del dispositivo.

Métodos de audio HAL

Audio Policy Manager utiliza los siguientes métodos para consultar las capacidades del dispositivo:

  • getParameters: un método genérico para recuperar valores de los parámetros específicos del proveedor, tales como formatos de audio y sus respectivas frecuencias de muestreo.
  • getAudioPort: Devuelve la lista de atributos compatibles (como las tasas de muestreo, formatos, máscaras de canales, controladores de ganancia) para un puerto de audio dada.

El siguiente código de IDevice.hal muestra la interfaz para el getAudioPort método:

   /**
    * 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 soportar múltiples perfiles de audio, la versión 3.2 de la API anterior se suma una nueva estructura llamada audio_port_v7 . Ver el código fuente para más detalles.

Debido a la adición de audio_port_v7 , la versión 3.2 de la API anterior se suma una nueva API denominada get_audio_port_v7 a las capacidades de consulta dispositivo usando el audio_port_v7 estructura.

El siguiente código de audio.h muestra la definición de la get_audio_port_v7 API:

/**
 * 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 herencia get_audio_port API tiene a poblarse en el nuevo AudioPort formato cuando la versión API anterior es inferior a 3.2 y la versión HIDL HAL es 7 o superior. En este caso, toda la informaron de frecuencias de muestreo y máscaras de canales de get_audio_port se asumen para ser compatible para todos los formatos devueltos, lo que permite una asignación directa de get_audio_port valores a la nueva AudioPort estructura.

Implementaciones de API de ejemplo

Esta sección describe varios conjuntos de pruebas que contienen métodos que utilizan las API cubiertas en las secciones anteriores. Consulte estos métodos para ver algunos ejemplos de cómo se implementan y utilizan estas API.

Un ejemplo de la utilización de los setPreferredDevicesForStrategy , getPreferredDevicesForStrategy , removePreferredDeviceForStrategy y OnPreferredDevicesForStrategyChangedListener API del sistema está en el PreferredDeviceRoutingTest método, que se encuentra en GTS.

Para ver un ejemplo de la nueva estructura en AudioDeviceInfo en uso, ver el AudioManagerTest#testGetDevices método que se encuentra en CTS.

Un ejemplo de la aplicación de get_audio_port_v7 se encuentra en audio_hal.c y muestra cómo se consultan las capacidades para múltiples dispositivos.

Validación

Esta sección proporciona información sobre CTS y GTS (Google Mobile Servicios Test Suite) validación del Administrador de audio.

Pruebas CTS

Pruebas CTS se encuentran en android.media.cts.AudioManagerTest .

La siguiente es la lista de pruebas de Audio Manager disponibles:

  • AudioManagerTest#testGetDevices

    Verifica las capacidades precisas del dispositivo de audio. También verifica que los perfiles de audio devueltos en el AudioDeviceInfo estructura de preservar el contenido de la mayor, formato de matriz aplanada, pero están en el nuevo AudioProfile formato.

  • AudioManagerTest#testPreferredDevicesForStrategy y AudioManagerTest#testPreferredDeviceForCapturePreset

    Verifique que los dispositivos preferidos para la estrategia y la captura de pruebas API relacionadas preestablecidas se completen con éxito.

Pruebas GTS

Pruebas GTS se encuentran en com.google.android.gts.audioservice.AudioServiceHostTest .

Para validar si las API para dispositivos preferidos para la estrategia y el trabajo preestablecido captura correctamente, ejecute el AudioServiceHostTest#testPreferredDeviceRouting y AudioServiceHostTest#testPreferredDeviceRoutingForCapturePreset pruebas.