O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Sound Trigger

O recurso Sound Trigger fornece aplicativos com a capacidade de ouvir certos eventos acústicos, como hotwords, de uma maneira de baixo consumo de energia e com privacidade. Os exemplos de casos de uso do Sound Trigger são Assistant e Now Playing.

Esta página oferece uma visão geral da arquitetura do 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: O som gatilho pilha

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 o som do disparador HAL de interface (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, aplicar permissões e lidar com a compatibilidade com versões mais antigas do HAL.

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

  • Acima da SoundTriggerService camada, a pilha (em marrom) alças recursos específicos para Assistente e aplicativos genéricos separadamente.

A função da pilha de acionadores de som é fornecer eventos discretos que representam eventos acústicos de acionamento. Na maioria dos casos, a pilha de acionadores de som não lida com áudio. Após o recebimento dos eventos de disparo, apps ter acesso ao fluxo de áudio real, em torno do tempo dos eventos, abrindo um AudioRecord objeto por meio da estrutura de áudio. As APIs HAL Sound Trigger fornecem um identificador com o evento disparado 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 de Sound Trigger e lida com o reconhecimento de hardware de hotwords e outros sons. O 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, em seguida, para a detecção.

A interface sthal é especificado sob /hardware/interfaces/soundtrigger/ .

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

O fluxo básico de configuração de uma sessão é explicado da seguinte forma na Figura 2:

sthal_state

Figura 2: diagrama de estado sthal

As etapas a seguir descrevem cada estado em mais detalhes:

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

  2. Uma vez que o modelo foi carregado com êxito, o cliente HAL chama startRecognition() para começar a detecção. O reconhecimento continua a ser executado em segundo plano até que um dos seguintes eventos ocorra:

    1. A stopRecognition() foi chamado este 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 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 nenhum retorno de chamada de reconhecimento é permitido.

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

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

Tratamento de erros HAL

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