Attivatore del suono

La funzione Sound Trigger fornisce alle app la possibilità di ascoltare determinati eventi acustici, come hotword, in modo a basso consumo e sensibile alla privacy. Esempi di casi d'uso di Sound Trigger sono Assistant e Now Playing.

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

Stack di attivazione del suono

Il sottosistema Sound Trigger è costruito a strati come mostrato nella Figura 1:

Figura 1: stack di trigger audio

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

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

• Il SoundTriggerMiddleware (in giallo) risiede sopra l'interfaccia HAL. Comunica con l'HAL ed è responsabile di funzionalità quali 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) risiede sopra il middleware. Facilita l'integrazione con altre funzionalità del sistema, come la telefonia e gli eventi della batteria. Mantiene inoltre un database di modelli sonori, indicizzati da ID univoci.

• Sopra il livello SoundTriggerService , lo stack (in marrone) gestisce separatamente le funzionalità specifiche dell'Assistente e delle app generiche.

La funzione dello stack Sound Trigger è quella di fornire eventi discreti che rappresentano eventi acustici e trigger. Nella maggior parte dei casi, lo stack Sound Trigger non si occupa dell'audio. Dopo aver ricevuto gli eventi di attivazione, le app ottengono l'accesso al flusso audio effettivo, che circonda il tempo degli eventi, aprendo un oggetto AudioRecord tramite il framework Audio. Le API HAL Sound Trigger forniscono un handle con l'evento attivato utilizzato con Audio Framework. Pertanto, poiché l'HAL Sound Trigger e l'HAL Audio sono collegati sotto il cofano, in genere condividono un processo.

Interfaccia HAL di attivazione del suono

L'interfaccia Sound Trigger HAL (STHAL) è la parte specifica del fornitore dello stack Sound Trigger e gestisce il riconoscimento hardware di hotword e altri suoni. STHAL fornisce uno o più motori, ciascuno dei quali esegue un algoritmo diverso 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 dato momento e di ascoltare eventi acustici. Una chiamata a ISoundTriggerHw.getProperties() restituisce una struttura Properties contenente la descrizione e le funzionalità dell'implementazione.

Il flusso di base per l'impostazione di una sessione è spiegato come segue nella Figura 2:

Figura 2: diagramma dello stato STHAL

I seguenti passaggi descrivono ciascuno 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 specifico dell'implementazione (motore) utilizzare, nonché i parametri applicabili per questo algoritmo. In caso di successo, questi metodi restituiscono un handle che viene utilizzato per fare riferimento a questo modello nelle chiamate successive.

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

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

   Negli ultimi due casi, un evento di riconoscimento viene inviato tramite l'interfaccia di callback registrata dal client HAL al momento del caricamento. In tutti i casi, dopo che si verifica 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 quante volte necessario.

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

Gestire gli errori HAL

Per garantire un comportamento affidabile e coerente tra le implementazioni dei driver, in Android 11, eventuali codici di errore non riusciti restituiti dall'HAL vengono trattati come errori di programmazione, il cui ripristino richiede il riavvio del processo HAL. Si tratta di una strategia di ripristino di ultima istanza e l'aspettativa è che tali casi non si verifichino in un sistema che funzioni correttamente.