Attivazione suono

La funzionalità Attivazione audio offre alle app la possibilità di ascoltare determinati eventi acustici, come le hotword, in modo a basso consumo e sensibile alla privacy. Esempi di casi d'uso di Sound Trigger sono l'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 è strutturato in livelli, come mostrato nella Figura 1:

sound_trigger_stack

Figura 1: stack di attivazione 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 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, 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à del sistema, come la telefonia e gli eventi della batteria. Inoltre, gestisce un database di modelli sonori, indicizzati in base a ID unici.

  • 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 di attivazione. Nella maggior parte dei casi, lo stack Sound Trigger non gestisce l'audio. Al ricevimento degli eventi trigger, le app accedono al flusso audio effettivo, che circonda l'ora 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é la HAL Sound Trigger e la HAL Audio sono connesse internamente, in genere condividono un processo.

Interfaccia HAL Sound Trigger

L'interfaccia Sound Trigger HAL (STHAL) è la parte specifica del fornitore dello stack 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 attivatore, 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 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à dell'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 in dettaglio ogni stato:

  1. Il client HAL carica un modello utilizzando loadSoundModel() o loadPhraseSoundModel(). L'oggetto modello fornito indica quale algoritmo di rilevamento (motore) specifico dell'implementazione utilizzare, nonché i parametri applicabili per 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 iniziare il rilevamento. Il riconoscimento continua a essere eseguito in background finché non si verifica uno dei seguenti eventi:

    1. È stato chiamato un stopRecognition() su questo modello.
    2. È stata rilevata una minaccia.
    3. Il rilevamento viene interrotto a causa di vincoli delle risorse, ad esempio quando è stato avviato un caso d'uso con priorità più elevata.

    Negli ultimi due casi, viene inviato un evento di riconoscimento tramite l'interfaccia di callback registrata dal client HAL al caricamento. In tutti i casi, dopo che si è verificato uno di questi eventi, il rilevamento diventa inattivo e non sono più consentiti callback di riconoscimento.

    Lo stesso modello può essere avviato di nuovo 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 ripristino richiede il riavvio del processo HAL. Si tratta di una strategia di recupero di ultima istanza e l'aspettativa è che questi casi non si verifichino in un sistema funzionante correttamente.