Acionador de som

O recurso Sound Trigger oferece aos aplicativos a capacidade de ouvir determinados eventos acústicos, como hotwords, com baixo consumo de energia e privacidade. Exemplos de casos de uso do Sound Trigger são Assistant e Now Playing.

Esta página fornece uma visão geral da arquitetura Sound Trigger e sua interface HAL (Hardware Abstraction Layer).

Pilha de acionadores de som

O subsistema Sound Trigger é construído em camadas, conforme mostrado na Figura 1:

sound_trigger_stack

Figura 1: pilha de acionadores de som

A lista a seguir descreve cada camada mostrada na Figura 1 com mais detalhes:

  • A camada HAL (em verde) contém o código específico do fornecedor que implementa a interface Sound Trigger HAL (STHAL).

  • O SoundTriggerMiddleware (em amarelo) reside acima da interface HAL. Ele se comunica com o HAL e é responsável por funcionalidades como compartilhar o HAL entre diferentes clientes, registrar, impor permissões e lidar com a compatibilidade com versões mais antigas do HAL.

  • O SoundTriggerService (em azul) reside acima do middleware. Facilita a integração com outros recursos do sistema, como telefonia e eventos de bateria. Também mantém um banco de dados de modelos de som, indexados por IDs únicos.

  • Acima da camada SoundTriggerService , a pilha (em marrom) lida com recursos específicos do Assistente e aplicativos genéricos separadamente.

A função da pilha Sound Trigger é fornecer eventos discretos que representam eventos acústicos de acionamento. Na maioria dos casos, a pilha Sound Trigger não lida com áudio. Após o recebimento dos eventos de gatilho, os aplicativos obtêm acesso ao fluxo de áudio real, em torno do tempo dos eventos, abrindo um objeto AudioRecord por meio da estrutura de áudio. As APIs de HAL do Sound Trigger fornecem um identificador com o evento acionado que é usado com o Audio Framework. Portanto, como o Sound Trigger HAL e o Audio HAL estão conectados sob o capô, eles normalmente compartilham um processo.

Interface HAL do acionador de som

A interface Sound Trigger HAL (STHAL) é a parte específica do fornecedor da pilha Sound Trigger e lida com o reconhecimento de hardware de hotwords e outros sons. O STHAL fornece um ou mais mecanismos com cada um executando um algoritmo diferente projetado para detectar uma classe específica de sons. Quando o STHAL detecta um gatilho, ele envia um evento para a estrutura e interrompe a detecção.

A interface STHAL é especificada em /hardware/interfaces/soundtrigger/ .

A interface ISoundTriggerHw suporta a capacidade de ter uma ou mais sessões de detecção em execução em um determinado momento e ouvir eventos acústicos. Uma chamada para ISoundTriggerHw.getProperties() retorna uma estrutura Properties contendo descrição de implementação e recursos.

O fluxo básico de configuração de uma sessão é explicado a seguir na Figura 2:

sthal_state

Figura 2: Diagrama de estado STHAL

As etapas a seguir descrevem cada estado com mais detalhes:

  1. O cliente HAL carrega um modelo usando loadSoundModel() ou loadPhraseSoundModel() . O objeto de modelo fornecido indica qual algoritmo de detecção específico de implementação (mecanismo) deve ser usado, bem como os parâmetros aplicáveis ​​a esse algoritmo. Após o sucesso, esses métodos retornam um identificador que é usado para fazer referência a esse modelo em chamadas subsequentes.

  2. Após o carregamento bem-sucedido do modelo, o cliente HAL chama startRecognition() para iniciar a detecção. O reconhecimento continua a ser executado em segundo plano até que ocorra um dos seguintes eventos:

    1. Um stopRecognition() foi chamado neste modelo.
    2. Ocorreu uma detecção.
    3. A detecção é interrompida devido a restrições de recursos, por exemplo, quando um caso de uso de prioridade mais alta foi iniciado.

    Nos dois últimos casos, um evento de reconhecimento é enviado por meio da interface de retorno de chamada registrada pelo cliente HAL durante o carregamento. Em todos os casos, após a ocorrência de qualquer um desses eventos, a detecção se torna inativa e não são permitidos mais retornos de chamada de reconhecimento.

    O mesmo modelo pode ser reiniciado posteriormente e esse processo pode ser repetido quantas vezes forem necessárias.

  3. Finalmente, um modelo inativo que não é mais necessário é descarregado pelo cliente HAL via unloadModel() .

Tratamento de erros de HAL

Para garantir um comportamento confiável e consistente entre as implementações de driver, no Android 11, quaisquer códigos de erro não bem-sucedidos retornados do HAL são tratados como erros de programação, cuja recuperação exige a reinicialização do processo HAL. Esta é uma estratégia de recuperação de último recurso e a expectativa é que tais casos não ocorram em um sistema funcionando corretamente.