Déclencheur de son

La fonctionnalité de déclencheur sonore permet aux applications d'écouter certains événements acoustiques, tels que les mots clés, de manière économe en énergie et respectueuse de la confidentialité. Exemples de cas d'utilisation de Déclencheur de son : Assistant et En écoute.

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

Pile du déclencheur de son

Le sous-système de déclenchement par son est construit en couches, comme illustré dans la figure 1:

Figure 1:Pile des déclencheurs de son

La liste suivante décrit plus en détail chaque couche illustrée à la figure 1:

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

  Remarque :Nous vous recommandons d'implémenter directement l'interface STHAL plutôt que de l'utiliser comme adaptateur autour d'une implémentation d'un ancien HAL.

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

• Le système SoundTriggerService (en bleu) se trouve au-dessus du middleware. Il facilite l'intégration avec d'autres fonctionnalités 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 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 diffuser des événements distincts qui représentent des événements déclencheurs acoustiques. Dans la plupart des cas, la pile de déclencheur de son ne gère pas l'audio. À la réception des événements de déclencheur, les applications accèdent au flux audio réel, autour de l'heure des événements, en ouvrant un objet AudioRecord via le framework Audio. Les API HAL Sound Trigger fournissent un gestionnaire avec l'événement déclenché qui est utilisé avec le framework audio. Par conséquent, comme le HAL Sound Trigger et le HAL Audio sont connectés en arrière-plan, ils partagent généralement un processus.

Remarque :Étant donné que les modèles et les types de données sont opaques pour le framework dans le sous-système de déclencheur de son, les applications et l'implémentation du HAL doivent respecter un "contrat caché", c'est-à-dire que le contenu, le format et la sémantique réels de ces types de données doivent être convenus. 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 du déclencheur de son

L'interface STHAL (Sound Trigger HAL) 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 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 permet d'exécuter une ou plusieurs sessions de détection à un moment donné et d'écouter des événements acoustiques. Un appel à ISoundTriggerHw.getProperties() renvoie une structure Properties contenant une description et des fonctionnalités d'implémentation.

La Figure 2 présente le déroulement de base de la configuration d'une session:

Figure 2:Schéma des états 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 de détection (moteur) à utiliser, ainsi que les paramètres applicables à cet algorithme. Si l'opération réussit, ces méthodes renvoient un gestionnaire qui permet de faire référence à 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 qu'un des événements suivants se produise:

   1. Un stopRecognition() a été appelé sur ce modèle.
   2. Une détection a été effectuée.
   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 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, après 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 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().

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 semblable à un événement de reconnaissance normal, mais son champ d'état est défini sur FORCED. Ces é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 l'envoi 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 renvoyés par le HAL en cas d'échec sont traités comme des erreurs de programmation, à partir desquelles vous devez relancer le processus HAL. Il s'agit d'une stratégie de reprise de dernier recours, et on s'attend à ce que de tels cas ne se produisent pas dans un système fonctionnant correctement.

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