Áudio HAL

A HAL (Hardware Abstraction Layer) de áudio do Android conecta as APIs de estrutura específicas de áudio de nível superior em android.media aos drivers de áudio e hardware subjacentes. O Audio HAL define a interface padrão para a qual os serviços de áudio chamam. Ele deve ser implementado para que o hardware de áudio funcione corretamente.

Esta página fornece uma visão geral do HAL de áudio e fornece detalhes de sua API e requisitos de implementação.

Interface de áudio HAL

A interface de áudio HAL é definida usando HIDL em arquivos .hal e esquemas XSD para os arquivos de configuração, mostrados a seguir.

Figura 1. Interface de áudio HAL

Arquivos de configuração

Os arquivos de configuração XML de política de áudio e efeitos de áudio são considerados parte da interface Audio HAL. Esses arquivos devem estar em conformidade com seus esquemas e a conformidade é verificada por testes VTS.

Como parte da implementação do áudio HAL, você deve criar um arquivo de configuração de política de áudio que descreva a topologia de áudio. Os recursos de áudio HAL devem ser declarados no arquivo audio_policy_configuration.xml para que a estrutura os use.

API HAL de áudio

O áudio HAL contém as seguintes APIs:

• Núcleo HAL
• Efeitos HAL
• HAL comum

Cada uma dessas APIs é descrita nas seções a seguir.

Núcleo HAL

O Core HAL é a principal API usada pelo AudioFlinger para reproduzir áudio e controlar o roteamento de áudio. Algumas das principais interfaces são as seguintes:

• IDeviceFactory.hal é o ponto de entrada na API.
• IDevice.hal e IPrimaryDevice.hal contêm métodos como setMasterVolume ou openInputStream .
• Os fluxos são unidirecionais e são usados ​​pelo AudioFlinger para enviar ou receber áudio de e para o HAL por meio de IStream.hal , IStreamOut.hal e IStreamIn.hal .

A tabela a seguir lista a localização de componentes úteis do Core HAL.

A implementação padrão da API Core HAL ( /hardware/interfaces/audio/core/all-versions/default/ ) é um wrapper em torno da implementação pré-Treble HAL usando bibliotecas compartilhadas legadas . A implementação padrão também pode ser considerada como referência ao implementar novas versões de HALs de áudio que interagem diretamente com os drivers do kernel.

Efeitos HAL

A API Effects HAL é usada pela estrutura de efeitos para controlar os efeitos de áudio. Você também pode configurar efeitos de pré -processamento, como controle automático de ganho e supressão de ruído por meio da API Effects HAL.

A tabela a seguir lista a localização de componentes úteis do Effects HAL.

Para obter mais informações, consulte um exemplo de implementação da API Effects HAL ( /hardware/interfaces/audio/effect/all-versions/default/ ) e a seção Audio Effects .

HAL comum

O Common HAL é uma biblioteca de tipos de dados comuns usados ​​pelas APIs Core e Effects HAL. Não possui interfaces nem testes VTS associados, pois apenas define estruturas de dados. A API HAL comum contém o seguinte:

• Definições ( /hardware/interfaces/audio/common/6.0/types.hal ) compartilhadas pelas APIs Core e Effect
• Utilitários ( /hardware/interfaces/audio/common/all-versions ) usados ​​para ajudar a codificar em APIs HIDL para implementações, clientes e testes

Requisitos

Além de implementar o áudio HAL e criar o arquivo de configuração de política de áudio, os seguintes requisitos de HAL devem ser atendidos:

• Se a captura para Sound Trigger (captura de hotword DSP buffer) for suportada por um perfil de entrada, a implementação deve suportar o número de fluxos ativos neste perfil correspondente ao número de sessões simultâneas suportadas pelo Sound Trigger HAL.
• Simultaneidade de TX de chamada de voz e captura do processador do aplicativo conforme detalhado na página Captura simultânea .

Atualizações para o Audio HAL V7

Para resolver problemas de compatibilidade com versões anteriores, o AIDL estável é obrigatório para todas as alterações de HAL a partir do Android T. Para oferecer suporte e aprimorar a adoção do AIDL no Android T e superior, o Audio HAL V7 faz o seguinte:

• Unifica os modelos de dados usados ​​pela estrutura e pela HAL.
• Minimiza a duplicação entre os tipos de dados HIDL (enums) e o esquema XML usado para configuração de política de áudio.

Especificamente, as alterações são feitas nas seguintes áreas no áudio HAL V7:

• Tipos de enumeração
• Tipos de dados
• Etiquetas do fornecedor
• Namespace das extensões do fornecedor

Essas mudanças são discutidas com mais detalhes em suas respectivas seções.

Enumerações

A partir do Audio HAL V7, os tipos enumerados usados ​​no arquivo Audio Policy Configuration são definidos apenas no esquema XSD e não no HIDL.

No áudio HAL V6, os valores dos tipos enum (como AudioFormat ) em types.hal também são definidos no esquema XSD do arquivo de configuração de política de áudio, criando uma duplicação. Para evitar isso na V7, os tipos de enumeração são alterados para string e todos os valores de enumeração possíveis são listados no esquema XSD.

Veja a figura 2 para uma comparação de algumas das mudanças no tipo de enumeração AudioFormat na V7.

Figura 2. Comparação de algumas das alterações na enumeração AudioFormat

Consulte a lista a seguir para os tipos de enumeração que foram convertidos em String :

• AudioChannelMask
• AudioContentType
• AudioDevice : extensível ao fornecedor
• AudioFormat : extensível ao fornecedor
• AudioGainMode
• AudioSource
• AudioStreamType
• AudioUsage

Passar valores de enumeração de string

Os valores de string são usados ​​para transferir informações como valores de enumeração no limite da interface HAL. Tanto a estrutura quanto o wrapper HAL usam valores de enumeração inteiros para implementar a lógica de negócios e empregam a abordagem de conversão descrita na figura 3 .

Figura 3. Passando valores enum de string

Como exemplo, para passar um valor do tipo de formato de áudio do framework para o fornecedor:

1. O valor enum de AudioFormat é convertido em um valor de string em libaudiohal e é passado para o HAL.
2. No lado HAL, o wrapper padrão converte a string em um valor enum, que é passado para o HAL legado.

Alterações de esquema XML

Ter listas completas de valores de enumeração na definição de esquema XML (XSD) permite uma melhor validação de arquivo XML de configuração de política de áudio pelo VTS. As alterações são feitas no arquivo de configuração de política de áudio usado com HAL V7 para estar em conformidade com XSD.

Na V7, um caractere padrão ␣ (espaço) é usado para delimitar listas de valores em atributos (como taxas de amostragem, máscaras de canal e sinalizadores), em vez de , (vírgula) e | (barra vertical) símbolos usados ​​na V6 e abaixo. Como visto no exemplo a seguir, um espaço é usado para delimitar a lista de valores para channelMasks :

<profile channelMasks="AUDIO_CHANNEL_OUT_STEREO AUDIO_CHANNEL_OUT_MONO" … />

Para fazer as alterações de símbolo, use um script de conversão automática chamado update_audio_policy_config.sh . Consulte o comando a seguir para converter um arquivo de configuração de política de áudio V6 em uma versão V7 para o 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 dados

Algumas estruturas de dados são redefinidas na V7 para minimizar definições duplicadas. Tuplas repetidas de itens de dados são agrupadas em estruturas reutilizáveis. Essas estruturas de dados usam os recursos HIDL mais recentes, como uniões seguras.

Por exemplo, na V6 e abaixo, um triplo de <format, sampling rate, channel mask> é usado frequentemente nas interfaces e tipos HIDL. Para remover essa redundância, na V7, o tipo de dados AudioConfigBase e outros tipos de dados são definidos da seguinte forma:

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

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

  usado por AudioConfig , AudioOffloadInfo , AudioPortConfig

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

  substitui coleções soltas em AudioPort/PortConfig

• AudioPortExtendedInfo := device | mix | session

  substitui uniões em AudioPort/PortConfig

Etiquetas do fornecedor

Além dos tipos e formatos de dispositivos, os fornecedores podem adicionar tags personalizadas para metadados de faixas de áudio.

Para metadados de faixa de reprodução e gravação, os fornecedores podem passar suas próprias tags, que são usadas para adicionar atributos a fluxos de E/S de áudio, dos aplicativos para o HAL.

As tags de fornecedor para metadados de faixa de reprodução são adicionadas conforme visto no exemplo a seguir:

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

A estrutura RecordTrackMetadata é implementada de maneira semelhante, adicionando tags específicas para os metadados da faixa de gravação.

Namespace das extensões do fornecedor

A partir do HAL V7, as extensões de fornecedor exigem um prefixo {vendor} adicional que não é necessário na V6. Para que o prefixo {vendor} seja válido, ele deve ter três ou mais caracteres alfanuméricos.

Use o seguinte formato na V7:

VX_{ vendor }_{ letters/numbers }

Veja a seguir alguns exemplos de extensões válidas do fornecedor V7:

• VX_GOOGLE_VR
• VX_QCI _AMBIENT_MIC

Versão informação

A tabela a seguir lista o número da versão HAL para cada versão do Android.