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 com 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 gatilho de som

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

sound_trigger_stack

Figura 1: Pilha Sound Trigger

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 sistema SoundTriggerService (em azul) reside acima do middleware. Facilita a integração com outras funcionalidades do sistema, como telefonia e eventos de bateria. Também mantém um banco de dados de modelos de som, indexados por IDs exclusivos.

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

A função da pilha Sound Trigger é fornecer eventos discretos que representam eventos acústicos de disparo. Na maioria dos casos, a pilha Sound Trigger não lida com áudio. Após o recebimento dos eventos acionadores, os aplicativos obtêm acesso ao fluxo de áudio real, próximo ao horário dos eventos, abrindo um objeto AudioRecord por meio da estrutura Audio. As APIs HAL do Sound Trigger fornecem um identificador com o evento acionado que é usado com o Audio Framework. Conseqüentemente, como o Sound Trigger HAL e o Audio HAL estão conectados internamente, eles normalmente compartilham um processo.

Interface HAL de gatilho 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. STHAL fornece um ou mais motores, 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 então 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 de ouvir eventos acústicos. Uma chamada para ISoundTriggerHw.getProperties() retorna uma estrutura Properties contendo descrição e recursos de implementação.

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 da implementação (mecanismo) usar, bem como os parâmetros aplicáveis ​​para este algoritmo. Após o sucesso, esses métodos retornam um identificador que é usado para referenciar esse modelo em chamadas subsequentes.

  2. Depois que o modelo for carregado com sucesso, 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 é abortada 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 através da interface de retorno de chamada registrada pelo cliente HAL no momento do carregamento. Em todos os casos, após a ocorrência de qualquer um destes eventos, a detecção torna-se inativa e não são permitidas mais chamadas 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() .

Lidar com erros HAL

Para garantir um comportamento confiável e consistente entre implementações de driver, no Android 11, quaisquer códigos de erro sem sucesso retornados do HAL são tratados como erros de programação, cuja recuperação requer 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.