Déclencheur sonore

La fonctionnalité de déclencheur audio permet aux applications d'écouter certains événements acoustiques, comme les mots clés, de manière économe en énergie et respectueuse de la confidentialité. L'Assistant et Now Playing sont des exemples de cas d'utilisation de Sound Trigger.

Cette page présente l'architecture Sound Trigger et son interface HAL (Hardware Abstraction Layer).

Pile de déclenchement audio

Le sous-système Sound Trigger est construit en couches, comme illustré à la figure 1 :

sound_trigger_stack

Figure 1 : Pile de déclencheur audio

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

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

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

  • Le système SoundTriggerService (en bleu) se trouve au-dessus du middleware. Il facilite l'intégration à d'autres fonctionnalités du système, telles que les événements de téléphonie et de batterie. Il gère également une base de données de modèles sonores, indexés par des ID 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 de déclenchement acoustiques. Dans la plupart des cas, la pile Sound Trigger ne traite pas l'audio. Lorsqu'elles reçoivent les événements de déclenchement, 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 HAL de déclencheur audio fournissent un handle avec l'événement déclenché qui est utilisé avec le framework audio. Par conséquent, étant donné que les HAL Sound Trigger et Audio sont connectés en interne, ils partagent généralement un processus.

Interface HAL de déclencheur audio

L'interface Sound Trigger HAL (STHAL) est la partie spécifique au fournisseur de la pile Sound Trigger. Elle gère la reconnaissance matérielle des mots clés et d'autres sons. STHAL fournit un ou plusieurs moteurs, chacun exécutant un algorithme différent conçu pour détecter une classe de sons spécifique. 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 permet 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 fonctionnalité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 de loadSoundModel() ou loadPhraseSoundModel(). L'objet de modèle fourni indique l'algorithme (moteur) de détection spécifique à l'implémentation à utiliser, ainsi que les paramètres applicables à cet algorithme. En cas de succès, ces méthodes renvoient un handle qui est utilisé pour référencer ce modèle dans les appels suivants.

  2. Une fois le modèle chargé, 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 abandonnée en raison de contraintes de ressources, par exemple lorsqu'un cas d'utilisation de priorité plus élevée a été lancé.

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

    Le même modèle peut être redémarré 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 le 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 reprise de dernier recours. L'idée est que de tels cas ne se produisent pas dans un système fonctionnant correctement.