Geräuschtrigger

Mit der Funktion „Sound Trigger“ können Apps auf bestimmte akustische Ereignisse wie Hotwords warten. Dies erfolgt auf energiesparende und datenschutzfreundliche Weise. Beispiele für Anwendungsfälle für Sound Trigger sind Assistant und Now Playing.

Auf dieser Seite erhalten Sie einen Überblick über die Architektur von Sound Trigger und die zugehörige HAL-Schnittstelle (Hardware Abstraction Layer).

Sound-Trigger-Stack

Das Sound Trigger-Subsystem ist in Schichten 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. Es kommuniziert mit dem HAL und ist für Funktionen wie die gemeinsame Nutzung des HAL zwischen verschiedenen Clients, die Protokollierung, die Durchsetzung von Berechtigungen und die Kompatibilität mit älteren HAL-Versionen verantwortlich.

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

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

Die Funktion des Sound Trigger-Stacks besteht darin, diskrete Ereignisse zu liefern, die akustische Triggerereignisse darstellen. In den meisten Fällen hat der Sound Trigger-Stack nichts mit Audio zu tun. Nach dem Empfang der Triggerereignisse erhalten Apps Zugriff auf den tatsächlichen Audiostream, der die Zeit der Ereignisse umgibt. Dazu wird über das Audio-Framework ein AudioRecord-Objekt geöffnet. Die Sound Trigger HAL APIs stellen ein Handle mit dem ausgelösten Ereignis bereit, das mit dem Audio Framework verwendet wird. Da die Sound Trigger HAL und die Audio HAL intern miteinander verbunden sind, verwenden sie in der Regel denselben Prozess.

HAL-Schnittstelle für Sound Trigger

Die Sound Trigger HAL-Schnittstelle (STHAL) ist der anbieterspezifische Teil des Sound Trigger-Stacks und verarbeitet die Hardwareerkennung von Hotwords und anderen Geräuschen. STHAL stellt eine oder mehrere Engines bereit, die jeweils einen anderen Algorithmus ausführen, der für die Erkennung einer bestimmten Klasse von Geräuschen entwickelt wurde. Wenn STHAL einen Trigger erkennt, wird ein Ereignis an das Framework gesendet und die Erkennung wird beendet.

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 akustische Ereignisse zu erfassen. Ein Aufruf von ISoundTriggerHw.getProperties() gibt eine Properties-Struktur mit Implementierungsbeschreibung und Funktionen zurück.

Der grundlegende Ablauf beim Einrichten einer Sitzung wird in Abbildung 2 so erklärt:

sthal_state

Abbildung 2:STHAL-Zustandsdiagramm

In den folgenden Schritten wird jeder Status 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 anwendbaren Parameter. Bei Erfolg geben diese Methoden einen Handle zurück, mit dem in nachfolgenden Aufrufen auf dieses Modell verwiesen wird.

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

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

    In den beiden letztgenannten Fällen wird über die Callback-Schnittstelle, die vom HAL-Client beim Laden registriert wird, ein Erkennungsereignis gesendet. In allen Fällen wird die Erkennung nach einem dieser Ereignisse inaktiv und es sind keine weiteren Rückrufe für die Erkennung zulässig.

    Dasselbe Modell kann zu einem späteren Zeitpunkt wieder 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() entladen.

HAL-Fehler beheben

Um ein zuverlässiges und konsistentes Verhalten zwischen Treiberimplementierungen zu gewährleisten, werden in Android 11 alle Fehlercodes, die nicht „Erfolg“ zurückgeben und vom HAL zurückgegeben werden, als Programmierfehler behandelt. Zur Wiederherstellung muss der HAL-Prozess neu gestartet werden. Dies ist eine Notfallwiederherstellungsstrategie. Es wird davon ausgegangen, dass solche Fälle in einem ordnungsgemäß funktionierenden System nicht auftreten.