Déclencheur sonore

La fonction Sound Trigger offre aux applications la possibilité d'écouter certains événements acoustiques, tels que les mots clés, de manière faible consommation et respectueuse de la confidentialité. Des exemples de cas d'utilisation de Sound Trigger sont Assistant et Now Playing.

Cette page donne un aperçu de l'architecture Sound Trigger et de son interface HAL (Hardware Abstraction Layer).

Pile de déclenchement sonore

Le sous-système Sound Trigger est construit en couches, comme le montre la figure 1 :

sound_trigger_stack

Figure 1 : Pile de déclencheurs sonores

La liste suivante décrit chaque couche présentée dans la figure 1 plus en détail :

  • La couche HAL (en vert) contient le code spécifique au fournisseur qui implémente l'interface Sound Trigger HAL (STHAL).

  • Le SoundTriggerMiddleware (en jaune) réside au-dessus de l'interface HAL. Il communique avec HAL et est responsable de fonctionnalités telles que le partage de HAL entre différents clients, la journalisation, l'application des autorisations et la gestion de la compatibilité avec les anciennes versions de HAL.

  • Le système SoundTriggerService (en bleu) réside au-dessus du middleware. Il facilite l'intégration avec d'autres fonctionnalités du système, telles que les événements de téléphonie et de batterie. Il maintient également une base de données de modèles sonores, indexés par des identifiants uniques.

  • Au-dessus de la couche SoundTriggerService , la pile (en marron) gère séparément les fonctionnalités spécifiques à l'Assistant et aux applications génériques.

La fonction de la pile Sound Trigger est de fournir des événements discrets qui représentent des événements déclencheurs acoustiques. Dans la plupart des cas, la pile Sound Trigger ne gère pas l’audio. Dès réception des événements déclencheurs, les applications ont accès au flux audio réel, entourant l'heure des événements, en ouvrant un objet AudioRecord via le framework Audio. Les API Sound Trigger HAL fournissent un handle avec l’événement déclenché qui est utilisé avec Audio Framework. Par conséquent, puisque le Sound Trigger HAL et l’Audio HAL sont connectés sous le capot, ils partagent généralement un processus.

Interface HAL de déclenchement sonore

L'interface Sound Trigger HAL (STHAL) est la partie spécifique au fournisseur de la pile Sound Trigger et gère la reconnaissance matérielle des mots clés et autres sons. STHAL fournit un ou plusieurs moteurs, chacun exécutant un algorithme différent conçu pour détecter une classe spécifique de sons. Lorsque STHAL détecte un déclencheur, il envoie un événement au framework puis arrête la détection.

L'interface STHAL est spécifiée sous /hardware/interfaces/soundtrigger/ .

L'interface ISoundTriggerHw prend en charge la possibilité d'exécuter une ou plusieurs sessions de détection à un moment donné et d'écouter les événements acoustiques. Un appel à ISoundTriggerHw.getProperties() renvoie une structure Properties contenant la description et les capacités de l'implémentation.

Le flux de base de configuration d’une session est expliqué comme suit dans la figure 2 :

sthal_state

Figure 2 : Diagramme d'état STHAL

Les étapes suivantes décrivent chaque état plus en détail :

  1. Le client HAL charge un modèle à l'aide loadSoundModel() ou loadPhraseSoundModel() . L'objet modèle fourni indique quel algorithme de détection (moteur) spécifique à l'implémentation utiliser, ainsi que les paramètres applicables pour cet algorithme. En cas de succès, ces méthodes renvoient un handle qui est utilisé pour référencer ce modèle lors des appels ultérieurs.

  2. Une fois le modèle chargé avec succès, le client HAL appelle startRecognition() pour commencer la détection. La reconnaissance continue de s'exécuter en arrière-plan jusqu'à ce que l'un des événements suivants se produise :

    1. Un stopRecognition() a été appelé sur ce modèle.
    2. Une détection a eu lieu.
    3. La détection est interrompue en raison de contraintes de ressources, par exemple lorsqu'un cas d'utilisation de priorité plus élevée a été lancé.

    Dans ces deux derniers cas, un événement de reconnaissance est envoyé via l'interface de rappel qui est enregistrée par le client HAL lors du chargement. Dans tous les cas, après l’apparition de l’un de ces événements, la détection devient inactive et aucun rappel de reconnaissance n’est autorisé.

    Le même modèle peut être relancé ultérieurement et ce processus peut être répété autant de fois que nécessaire.

  3. Enfin, un modèle inactif qui n'est plus nécessaire est déchargé par le client HAL via unloadModel() .

Gérer les erreurs HAL

Pour garantir un comportement fiable et cohérent entre les implémentations de pilotes, dans Android 11, tous les codes d'erreur non réussis renvoyés par HAL sont traités comme des erreurs de programmation, dont la récupération nécessite le redémarrage du processus HAL. Il s'agit d'une stratégie de récupération de dernier recours et l'on s'attend à ce que de tels cas ne se produisent pas dans un système fonctionnant correctement.