HAL de audio

La capa de abstracción de hardware (HAL) de audio de Android conecta las API del marco específicas de audio de nivel superior en android.media con los controladores de audio y el hardware subyacentes. Audio HAL define la interfaz estándar a la que llaman los servicios de audio. Debe implementarse para que el hardware de audio funcione correctamente.

Esta página brinda una descripción general de la HAL de audio y brinda detalles de su API y los requisitos de implementación.

Interfaz HAL de audio

La interfaz HAL de audio se define mediante HIDL en archivos .hal y esquemas XSD para los archivos de configuración, como se muestra a continuación.

Figura 1. Interfaz HAL de audio

Archivos de configuración

Los archivos de configuración XML de políticas de audio y efectos de audio se consideran parte de la interfaz HAL de audio. Estos archivos deben ajustarse a sus esquemas y la conformidad se verifica mediante pruebas VTS.

Como parte de la implementación de la HAL de audio, debe crear un archivo de configuración de política de audio que describa la topología de audio. Las capacidades HAL de audio deben declararse en el archivo audio_policy_configuration.xml para que el marco las use.

API HAL de audio

La HAL de audio contiene las siguientes API:

• Núcleo HAL
• Efectos HAL
• HAL común

Cada una de estas API se describe en las siguientes secciones.

Núcleo HAL

Core HAL es la API principal utilizada por AudioFlinger para reproducir audio y controlar el enrutamiento de audio. Algunas de las interfaces clave son las siguientes:

• IDeviceFactory.hal es el punto de entrada a la API.
• IDevice.hal e IPrimaryDevice.hal contienen métodos como setMasterVolume o openInputStream .
• Los flujos son unidireccionales y AudioFlinger los utiliza para enviar o recibir audio hacia y desde HAL a través de IStream.hal , IStreamOut.hal e IStreamIn.hal .

La siguiente tabla enumera la ubicación de los componentes Core HAL útiles.

La implementación predeterminada de la API Core HAL ( /hardware/interfaces/audio/core/all-versions/default/ ) es un contenedor de la implementación anterior a Treble HAL que utiliza bibliotecas compartidas heredadas . La implementación predeterminada también se puede considerar como una referencia al implementar nuevas versiones de HAL de audio que interactúan directamente con los controladores del kernel.

Efectos HAL

La API Effects HAL es utilizada por el framework de efectos para controlar los efectos de audio. También puede configurar efectos de preprocesamiento , como el control automático de ganancia y la supresión de ruido, a través de la API HAL de efectos.

La siguiente tabla enumera la ubicación de los componentes útiles de Effects HAL.

Para obtener más información, consulte una implementación de muestra de la API HAL de efectos ( /hardware/interfaces/audio/effect/all-versions/default/ ) y la sección Efectos de audio .

HAL común

Common HAL es una biblioteca de tipos de datos comunes utilizados por las API HAL principales y de efectos. No tiene interfaces ni pruebas VTS asociadas, ya que solo define estructuras de datos. La API HAL común contiene lo siguiente:

• Definiciones ( /hardware/interfaces/audio/common/6.0/types.hal ) compartidas por las API Core y Effect
• Utilidades ( /hardware/interfaces/audio/common/all-versions ) utilizadas para ayudar a codificar contra las API de HIDL para implementaciones, clientes y pruebas

Requisitos

Además de implementar la HAL de audio y crear el archivo de configuración de la política de audio, se deben cumplir los siguientes requisitos de HAL:

• Si la captura para Sound Trigger (captura del búfer DSP de palabra activa) es compatible con un perfil de entrada, la implementación debe admitir la cantidad de secuencias activas en este perfil correspondiente a la cantidad de sesiones simultáneas admitidas por Sound Trigger HAL.
• Simultaneidad de transmisión de llamadas de voz y captura desde el procesador de la aplicación, como se detalla en la página Captura simultánea .

Actualizaciones al Audio HAL V7

Para abordar los problemas de compatibilidad con versiones anteriores, Stable AIDL es obligatorio para todos los cambios de HAL a partir de Android T. Para admitir y mejorar la adopción de AIDL en Android T y superior, Audio HAL V7 hace lo siguiente:

• Unifica los modelos de datos utilizados por el marco y HAL.
• Minimiza la duplicación entre los tipos de datos HIDL (enumeraciones) y el esquema XML utilizado para la configuración de la política de audio.

Específicamente, se realizan cambios en las siguientes áreas en audio HAL V7:

• Tipos de enumeración
• Tipos de datos
• Etiquetas de proveedor
• Espacio de nombres de extensiones de proveedor

Estos cambios se analizan con más detalle en sus respectivas secciones.

enumeraciones

A partir de Audio HAL V7, los tipos enumerados utilizados en el archivo de configuración de políticas de audio solo se definen en el esquema XSD y no en HIDL.

En audio HAL V6, los valores de tipos de enumeración (como AudioFormat ) en types.hal también se definen en el esquema XSD del archivo de configuración de política de audio, creando una duplicación. Para evitar esto en V7, los tipos de enumeración se cambian a string y, en su lugar, todos los valores de enumeración posibles se enumeran en el esquema XSD.

Consulte la figura 2 para ver una comparación de algunos de los cambios en el tipo de enumeración AudioFormat en V7.

Figura 2. Comparación de algunos de los cambios en la enumeración AudioFormat

Consulte la siguiente lista para ver los tipos de enumeración que se han convertido a String :

• AudioChannelMask
• AudioContentType
• AudioDevice : proveedor extensible
• AudioFormat : proveedor extensible
• AudioGainMode
• AudioSource
• AudioStreamType
• AudioUsage

Pasar valores de enumeración de cadena

Los valores de cadena se utilizan para transferir información como valores de enumeración a través del límite de la interfaz HAL. Tanto el marco como el contenedor HAL utilizan valores de enumeración enteros para implementar la lógica empresarial y emplean el enfoque de conversión que se muestra en la figura 3 .

Figura 3. Pasar valores de enumeración de cadena

Como ejemplo, para pasar un valor de tipo de formato de audio del marco al proveedor:

1. El valor de enumeración de AudioFormat se convierte en un valor de cadena en libaudiohal y se pasa a la HAL.
2. En el lado de HAL, el contenedor predeterminado convierte la cadena en un valor de enumeración, que se pasa a la HAL heredada.

Cambios en el esquema XML

Tener listas completas de valores de enumeración en la definición de esquema XML (XSD) permite una mejor configuración de políticas de audio y validación de archivos XML por parte de VTS. Los cambios se realizan en el archivo de configuración de la política de audio que se usa con HAL V7 para cumplir con XSD.

En V7, se usa un carácter ␣ (espacio) estándar para delimitar listas de valores en atributos (como frecuencias de muestreo, máscaras de canal y banderas), en lugar de , (coma) y | (barra vertical) símbolos utilizados en V6 y versiones anteriores. Como se ve en el siguiente ejemplo, se usa un espacio para delimitar la lista de valores para channelMasks :

<profile channelMasks="AUDIO_CHANNEL_OUT_STEREO AUDIO_CHANNEL_OUT_MONO" … />

Para realizar los cambios de símbolo, use un script de conversión automática llamado update_audio_policy_config.sh . Consulte el siguiente comando para convertir un archivo de configuración de política de audio V6 a una versión V7 para el dispositivo Pixel 5 (Redfin):

hardware/interfaces/audio/7.0/config/update_audio_policy_config.sh \
device/google/redfin/audio/audio_policy_configuration.xml 6.0

Tipos de datos

Algunas estructuras de datos se redefinen en V7 para minimizar las definiciones duplicadas. Las tuplas repetidas de elementos de datos se agrupan en estructuras reutilizables. Estas estructuras de datos utilizan las funciones HIDL más recientes, como uniones seguras.

Por ejemplo, en V6 y anteriores, se usa a menudo un triple de <format, sampling rate, channel mask> en las interfaces y tipos de HIDL. Para eliminar esta redundancia, en V7, el tipo de datos AudioConfigBase y otros tipos de datos se definen de la siguiente manera:

• AudioConfigBase := <format, sampling rate, channel mask>

• AudioConfigBaseOptional := <[fmt], [sampl. rate], [chan. mask]>

  utilizado por AudioConfig , AudioOffloadInfo , AudioPortConfig

• AudioProfile := <format, {sampling rates}, {channel masks}>

  reemplaza colecciones sueltas en AudioPort/PortConfig

• AudioPortExtendedInfo := device | mix | session

  reemplaza uniones en AudioPort/PortConfig

Etiquetas de proveedor

Además de los tipos y formatos de dispositivos, los proveedores pueden agregar etiquetas personalizadas para metadatos de pistas de audio.

Para los metadatos de la pista de reproducción y grabación, los proveedores pueden pasar sus propias etiquetas, que se utilizan para agregar atributos a los flujos de E/S de audio, desde las aplicaciones a la HAL.

Las etiquetas de proveedor para los metadatos de la pista de reproducción se agregan como se ve en el siguiente ejemplo:

struct PlaybackTrackMetadata {
…
    /** Tags from AudioTrack audio attributes */
    vec<AudioTag> tags;
};

La estructura RecordTrackMetadata se implementa de manera similar agregando etiquetas específicas para los metadatos de la pista de grabación.

Espacio de nombres de extensiones de proveedor

A partir de HAL V7, las extensiones de proveedor requieren un prefijo {vendor} adicional que no se requiere en V6. Para que el prefijo {vendor} sea válido, debe tener tres o más caracteres alfanuméricos.

Utilice el siguiente formato en V7:

VX_{ vendor }_{ letters/numbers }

Los siguientes son algunos ejemplos de extensiones válidas de proveedores de V7:

• VX_GOOGLE_VR
• VX_QCI_AMBIENT_MIC

Información de versión

La siguiente tabla enumera el número de versión de HAL para cada versión de Android.