Attivatore sonoro

La funzionalità Attivazione tramite suono offre alle app la possibilità di rilevare determinati eventi acustici, come le hotword, in modo parsimonioso e rispettoso della privacy. Esempi di casi d'uso dell'attivatore di suoni sono Assistente e In riproduzione.

Questa pagina fornisce una panoramica dell'architettura di Sound Trigger e della relativa interfaccia HAL (Hardware Abstraction Layer).

Stack di trigger audio

Il sottosistema di attivazione acustica è costituito da livelli, come mostrato nella Figura 1:

sound_trigger_stack

Figura 1: pila di trigger audio

L'elenco seguente descrive in modo più dettagliato ogni livello mostrato nella Figura 1:

  • Il livello HAL (in verde) contiene il codice specifico del fornitore che implementa l'interfaccia HAL di attivazione audio (STHAL).

  • SoundTriggerMiddleware (in giallo) si trova sopra l'interfaccia HAL. Comunica con l'HAL ed è responsabile di funzionalità come la condivisione dell'HAL tra diversi client, la registrazione, l'applicazione delle autorizzazioni e la gestione della compatibilità con le versioni precedenti dell'HAL.

  • Il sistema SoundTriggerService (in blu) si trova sopra il middleware. Facilita l'integrazione con altre funzionalità di sistema, come la telefonia e gli eventi relativi alla batteria. Inoltre, gestisce un database di modelli audio, indicizzato tramite ID unici.

  • Sopra il livello SoundTriggerService, la serie (in marrone) gestisce separatamente le funzionalità specifiche dell'assistente e delle app generiche.

La funzione dello stack di trigger acustici è fornire eventi discreti che rappresentano eventi di trigger acustici. Nella maggior parte dei casi, la pila dell'attivatore audio non si occupa dell'audio. Al ricevimento degli eventi di attivazione, le app ottengono l'accesso allo stream audio effettivo, intorno al momento degli eventi, aprendo un oggetto AudioRecord tramite il framework Audio. Le API HAL Sound Trigger forniscono un handle con l'evento attivato che viene utilizzato con il framework audio. Pertanto, poiché HAL Sound Trigger e HAL Audio sono collegati sotto il cofano, in genere condividono un processo.

Interfaccia HAL di Sound Trigger

L'interfaccia HAL (STHAL) di attivazione tramite suono è la parte specifica del fornitore dello stack di attivazione tramite suono e gestisce il riconoscimento hardware di hotword e altri suoni. STHAL fornisce uno o più motori, ognuno dei quali esegue un algoritmo diverso progettato per rilevare una classe specifica di suoni. Quando STHAL rileva un attivatore, invia un evento al framework e interrompe il rilevamento.

L'interfaccia STHAL è specificata in /hardware/interfaces/soundtrigger/.

L'interfaccia ISoundTriggerHw supporta la possibilità di avere una o più sessioni di rilevamento in esecuzione in un determinato momento e di ascoltare gli eventi acustici. Una chiamata a ISoundTriggerHw.getProperties() restituisce una struttura Properties contenente la descrizione e le funzionalità di implementazione.

Il flusso di base per la configurazione di una sessione è spiegato come segue nella Figura 2:

sthal_state

Figura 2: diagramma di stato STHAL

I passaggi seguenti descrivono ogni stato in modo più dettagliato:

  1. Il client HAL carica un modello utilizzando loadSoundModel() o loadPhraseSoundModel(). L'oggetto modello fornito indica quale algoritmo di rilevamento (motore) specifico per l'implementazione da utilizzare, nonché i parametri applicabili a questo algoritmo. In caso di esito positivo, questi metodi restituiscono un handle utilizzato per fare riferimento a questo modello nelle chiamate successive.

  2. Una volta caricato il modello, il client HAL chiama startRecognition() per avviare il rilevamento. Il riconoscimento continua a essere eseguito in background finché non si verifica uno dei seguenti eventi:

    1. Per questo modello è stato chiamato un stopRecognition().
    2. Si è verificato un rilevamento.
    3. Il rilevamento viene interrotto a causa di limitazioni delle risorse, ad esempio quando è stato avviato un caso d'uso con priorità più elevata.

    Nei due casi successivi, viene inviato un evento di riconoscimento tramite l'interfaccia di callback registrata dal client HAL al momento del caricamento. In tutti i casi, dopo la verifica di uno di questi eventi, il rilevamento diventa inattivo e non sono più consentiti callback di riconoscimento.

    Lo stesso modello può essere riavviato in un secondo momento e questa procedura può essere ripetuta tutte le volte che è necessario.

  3. Infine, un modello inattivo che non è più necessario viene scaricato dal cliente HAL tramite unloadModel().

Gestire gli errori HAL

Per garantire un comportamento affidabile e coerente tra le implementazioni dei driver, in Android 11 tutti i codici di errore di mancato buon esito restituiti dall'HAL vengono trattati come errori di programmazione, il cui recupero richiede il riavvio del processo HAL. Si tratta di una strategia di recupero di ultima istanza e si prevede che questi casi non si verifichino in un sistema che funziona correttamente.