Geräuschtrigger

Mit der Funktion „Sound Trigger“ können Apps auf bestimmte akustische Ereignisse wie Hotwords hören, und zwar auf energieeffiziente und datenschutzfreundliche Weise. Beispiele für Anwendungsfälle von Sound Trigger sind Assistant und „Now Playing“.

Auf dieser Seite finden Sie eine Übersicht über die Sound Trigger-Architektur und die zugehörige Hardwareabstraktionsschicht (HAL)-Schnittstelle.

Sound Trigger-Stack

Das Sound Trigger-Subsystem ist in Ebenen aufgebaut, wie in Abbildung 1 dargestellt:

sound_trigger_stack

Abbildung 1:Sound Trigger-Stack

In der folgenden Liste werden die einzelnen Ebenen in Abbildung 1 genauer beschrieben:

  • Die HAL-Ebene (grün) enthält den anbieterspezifischen Code, der die Sound Trigger HAL-Schnittstelle (STHAL) implementiert.

  • Die SoundTriggerMiddleware (gelb) befindet sich über der HAL-Schnittstelle. Sie kommuniziert mit der HAL und ist für Funktionen wie die gemeinsame Nutzung der HAL durch verschiedene Clients, die Protokollierung, die Durchsetzung von Berechtigungen und die Kompatibilität mit älteren HAL-Versionen zuständig.

  • Das SoundTriggerService -System (blau) befindet sich über der Middleware. Es ermöglicht die Integration mit anderen Systemfunktionen wie Telefonie- und Akkuereignissen. Außerdem wird eine Datenbank mit Soundmodellen verwaltet, die nach eindeutigen IDs indexiert sind.

  • Über der SoundTriggerService-Ebene verarbeitet der Stack (braun) Funktionen, die spezifisch für Assistant und generische Apps sind, separat.

Die Funktion des Sound Trigger-Stacks besteht darin, diskrete Ereignisse zu liefern, die akustische Triggerereignisse darstellen. In den meisten Fällen befasst sich der Sound Trigger-Stack nicht mit Audio. Nach dem Empfang der Triggerereignisse erhalten Apps Zugriff auf den tatsächlichen Audiostream, der die Zeit der Ereignisse umgibt, indem sie über das Audio-Framework ein AudioRecord-Objekt öffnen. Die Sound Trigger HAL-APIs bieten ein Handle mit dem ausgelösten Ereignis, das mit dem Audio-Framework verwendet wird. Da die Sound Trigger HAL und die Audio HAL unter der Haube verbunden sind, verwenden sie in der Regel einen gemeinsamen Prozess.

Sound Trigger HAL-Schnittstelle

Die Sound Trigger HAL-Schnittstelle (STHAL) ist der anbieterspezifische Teil des Sound Trigger-Stacks und verarbeitet die Hardwareerkennung von Hotwords und anderen Sounds. STHAL bietet eine oder mehrere Engines, die jeweils einen anderen Algorithmus ausführen, der für die Erkennung einer bestimmten Soundklasse entwickelt wurde. Wenn STHAL einen Trigger erkennt, sendet es ein Ereignis an das Framework und beendet dann die Erkennung.

Die STHAL-Schnittstelle ist unter /hardware/interfaces/soundtrigger/ angegeben.

Die ISoundTriggerHw-Schnittstelle unterstützt die Möglichkeit, eine oder mehrere Erkennungssitzungen gleichzeitig auszuführen und auf akustische Ereignisse zu hören. Ein Aufruf von ISoundTriggerHw.getProperties() gibt eine Properties Struktur mit einer Implementierungsbeschreibung und -funktionen zurück.

Der grundlegende Ablauf der Einrichtung einer Sitzung wird in Abbildung 2 erläutert:

sthal_state

Abbildung 2:STHAL-Zustandsdiagramm

In den folgenden Schritten werden die einzelnen Zustände genauer beschrieben:

  1. Der HAL-Client lädt ein Modell mit loadSoundModel() oder loadPhraseSoundModel(). Das bereitgestellte Modellobjekt gibt an, welcher implementierungsspezifische Erkennungsalgorithmus (Engine) verwendet werden soll, sowie die für diesen Algorithmus geltenden Parameter. Bei Erfolg geben diese Methoden ein Handle zurück, mit dem auf dieses Modell in nachfolgenden Aufrufen verwiesen wird.

  2. Sobald das Modell erfolgreich geladen wurde, ruft der HAL-Client startRecognition() auf, um die Erkennung zu starten. Die Erkennung wird im Hintergrund fortgesetzt, bis eines der folgenden Ereignisse eintritt:

    1. Für dieses Modell wurde stopRecognition() aufgerufen.
    2. Es wurde eine Erkennung durchgeführt.
    3. Die Erkennung wird aufgrund von Ressourcenbeschränkungen abgebrochen, z. B. wenn ein Anwendungsfall mit höherer Priorität initiiert wurde.

    In den letzten beiden Fällen wird ein Erkennungsereignis über die Callback-Schnittstelle gesendet, die vom HAL-Client beim Laden registriert wird. In allen Fällen wird die Erkennung nach dem Eintreten eines dieser Ereignisse inaktiv und es sind keine weiteren Erkennungs-Callbacks zulässig.

    Dasselbe Modell kann später noch einmal gestartet werden. Dieser Vorgang kann beliebig oft wiederholt werden.

  3. Schließlich wird ein inaktives Modell, das nicht mehr benötigt wird, vom HAL-Client über unloadModel() entfernt.

HAL-Fehler verarbeiten

Um ein zuverlässiges und konsistentes Verhalten zwischen Treiberimplementierungen zu gewährleisten, werden in Android 11 alle nicht erfolgreichen Fehlercodes, die von der HAL zurückgegeben werden, als Programmierfehler behandelt. Zur Behebung dieser Fehler muss der HAL-Prozess neu gestartet werden. Dies ist eine Notfallstrategie zur Wiederherstellung. Es wird erwartet, dass solche Fälle in einem ordnungsgemäß funktionierenden System nicht auftreten.