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 :

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

  Remarque : Une implémentation directe de l'interface STHAL est recommandée plutôt que comme adaptateur autour d'une implémentation d'un HAL existant.

• 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.

Remarque : Étant donné que les modèles et les types de données sont opaques au cadre du sous-système Sound Trigger, il est prévu que les applications et l'implémentation de HAL maintiennent un « contrat caché », c'est-à-dire que le contenu, le format et la sémantique réels de ces types de données sont convenus. sur. Par conséquent, les applications utilisant Sound Trigger sont destinées à être fournies par des fournisseurs plutôt que par des développeurs indépendants.

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 :

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() .

Remarque : Lorsqu'un modèle est démarré, le client HAL peut appeler forceRecognitionEvent() pour générer un événement de reconnaissance forcée. L'événement renvoyé est similaire à un événement de reconnaissance normal, mais son champ d'état est défini sur FORCED . De tels événements de reconnaissance n'arrêtent pas automatiquement la reconnaissance. Au lieu de cela, l'état du modèle reste en cours d'exécution même après la livraison de l'événement.

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.

Remarque : Bien que ces erreurs soient considérées comme valides dans la documentation de l'API HAL, il existe une ambiguïté quant au moment et aux états dans lesquels ces codes d'erreur sont renvoyés et à la procédure de récupération d'erreur attendue. Par conséquent, Android 11 impose une conformité plus stricte des implémentations Sound Trigger HAL au moment de l’exécution que les versions inférieures d’Android.