Attivazione suono

La funzionalità Sound Trigger consente alle app di ascoltare determinati eventi acustici, come le hotword, in modo a basso consumo energetico e rispettoso della privacy. Esempi di casi d'uso di Sound Trigger sono Assistente e Now Playing.

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

Stack di Sound Trigger

Il sottosistema Sound Trigger è creato a livelli, come mostrato nella Figura 1:

Figura 1: stack di Sound Trigger

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) 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 HAL precedenti.

• Il sistema SoundTriggerService (in blu) si trova sopra il middleware. Facilita l'integrazione con altre funzionalità di sistema, come gli eventi di telefonia e batteria. Gestisce anche un database di modelli audio, indicizzati per ID univoci.

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

La funzione dello stack di Sound Trigger è di fornire eventi discreti che rappresentano eventi acustici e di attivazione. Nella maggior parte dei casi, lo stack di Sound Trigger non gestisce l'audio. Al ricevimento degli eventi di attivazione, le app accedono al flusso audio effettivo, che circonda il momento degli eventi, aprendo un oggetto AudioRecord tramite il framework audio. Le API Sound Trigger HAL forniscono un handle con l'evento attivato utilizzato con il framework audio. Pertanto, poiché Sound Trigger HAL e Audio HAL sono connessi in background, in genere condividono un processo.

Interfaccia Sound Trigger HAL

L'interfaccia Sound Trigger HAL (STHAL) è la parte specifica del fornitore dello stack di Sound Trigger e gestisce il riconoscimento hardware delle hotword e di 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 trigger, invia un evento al framework e poi interrompe il rilevamento.

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

L'interfaccia ISoundTriggerHw supporta la possibilità di eseguire una o più sessioni di rilevamento contemporaneamente e di ascoltare gli eventi acustici. Una chiamata a ISoundTriggerHw.getProperties() restituisce una struttura Properties contenente la descrizione e le funzionalità dell'implementazione.

Il flusso di base per la configurazione di una sessione è spiegato di seguito 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 l'algoritmo di rilevamento (motore) specifico dell'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 correttamente 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. È stato chiamato stopRecognition() su questo modello.
   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ù alta.

   Negli ultimi due casi, viene inviato un evento di riconoscimento 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 tutte le volte che è 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 tutti i codici di errore non riusciti 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 funzionante correttamente.