Attivatore sonoro

La funzionalità di 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 sonori

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

Figura 1: pila di attivatori audio

L'elenco seguente descrive in dettaglio ogni livello mostrato nella Figura 1:

• Il livello HAL (in verde) contiene il codice specifico del fornitore che implementa l'interfaccia Sound Trigger HAL (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, il logging, 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. Semplifica l'integrazione con altre funzionalità del sistema, come la telefonia e gli eventi della 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 Sound Trigger HAL forniscono un handle con l'evento attivato che viene utilizzato con il framework audio. Pertanto, poiché gli HAL Sound Trigger e 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 diverso algoritmo, progettato per rilevare una specifica classe di suoni. Quando STHAL rileva un trigger, invia un evento al framework e quindi 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:

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. stopRecognition() è stato chiamato su questo modello.
   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 questo processo può essere ripetuto 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. Questa è una strategia di recupero dell'ultima risorsa e ci si aspetta che questi casi non si verifichino in un sistema che funziona correttamente.