Tonauslöser

Die Sound Trigger-Funktion bietet Apps die Möglichkeit, auf stromsparende und datenschutzbewusste Weise auf bestimmte akustische Ereignisse wie Hotwords zu achten. Beispielhafte Anwendungsfälle für Sound Trigger sind Assistant und Now Playing.

Diese Seite gibt einen Überblick über die Sound Trigger-Architektur und ihre HAL-Schnittstelle (Hardware Abstraction Layer).

Sound-Trigger-Stapel

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

sound_trigger_stack

Abbildung 1: Sound-Trigger-Stapel

In der folgenden Liste werden die einzelnen in Abbildung 1 dargestellten Schichten ausführlicher beschrieben:

  • Die HAL-Schicht (in Grün) enthält den herstellerspezifischen Code, der die Sound Trigger HAL (STHAL)-Schnittstelle implementiert.

  • Die SoundTriggerMiddleware (in 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 Handhabung der Kompatibilität mit älteren HAL-Versionen verantwortlich.

  • Das SoundTriggerService System (in Blau) befindet sich über der Middleware. Es erleichtert die Integration mit anderen Systemfunktionen wie Telefonie und Batterieereignissen. Es verwaltet außerdem eine Datenbank mit Klangmodellen, die durch eindeutige IDs indiziert sind.

  • Oberhalb der SoundTriggerService Ebene verarbeitet der Stapel (in Braun) Funktionen, die für Assistant- und generische Apps spezifisch sind, getrennt.

Die Funktion des Sound-Trigger-Stacks besteht darin, diskrete Ereignisse zu liefern, die akustische Trigger-Ereignisse darstellen. In den meisten Fällen verarbeitet der Sound Trigger-Stack kein Audio. Nach Erhalt der Auslöseereignisse erhalten Apps Zugriff auf den tatsächlichen Audiostream rund um den Zeitpunkt der Ereignisse, indem sie über das Audio-Framework ein AudioRecord Objekt öffnen. Die Sound Trigger HAL-APIs stellen ein Handle mit dem ausgelösten Ereignis bereit, das mit dem Audio Framework verwendet wird. Da Sound Trigger HAL und Audio HAL unter der Haube miteinander verbunden sind, teilen sie sich normalerweise einen Prozess.

Sound Trigger HAL-Schnittstelle

Die Sound Trigger HAL (STHAL)-Schnittstelle ist der herstellerspezifische Teil des Sound Trigger-Stacks und übernimmt die Hardware-Erkennung von Hotwords und anderen Sounds. STHAL stellt eine oder mehrere Engines bereit, von denen jede einen anderen Algorithmus ausführt, der darauf ausgelegt ist, eine bestimmte Klasse von Geräuschen zu erkennen. Wenn STHAL einen Auslöser erkennt, sendet es ein Ereignis an das Framework und stoppt 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 akustische Ereignisse abzuhören. Ein Aufruf von ISoundTriggerHw.getProperties() gibt eine Properties Struktur zurück, die eine Implementierungsbeschreibung und Funktionen enthält.

Der grundlegende Ablauf beim Einrichten einer Sitzung wird in Abbildung 2 wie folgt erläutert:

sthal_state

Abbildung 2: STHAL-Zustandsdiagramm

Die folgenden Schritte beschreiben jeden Zustand detaillierter:

  1. Der HAL-Client lädt ein Modell mit loadSoundModel() oder loadPhraseSoundModel() . Das bereitgestellte Modellobjekt gibt an, welcher umsetzungsspezifische Erkennungsalgorithmus (Engine) verwendet werden soll, sowie die für diesen Algorithmus anwendbaren Parameter. Bei Erfolg geben diese Methoden ein 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 Erkennung läuft im Hintergrund weiter, bis eines der folgenden Ereignisse eintritt:

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

    In den beiden letztgenannten Fällen wird über die Callback-Schnittstelle ein Erkennungsereignis gesendet, das beim Laden vom HAL-Client registriert wird. In allen Fällen wird die Erkennung nach Eintreten eines dieser Ereignisse inaktiv und es sind keine Erkennungsrückrufe mehr zulässig.

    Dasselbe Modell kann zu einem späteren Zeitpunkt erneut gestartet werden und dieser Vorgang kann beliebig oft wiederholt werden.

  3. Abschließend wird ein inaktives Modell, das nicht mehr benötigt wird, vom HAL-Client über unloadModel() entladen.

Behandeln Sie HAL-Fehler

Um ein zuverlässiges und konsistentes Verhalten zwischen Treiberimplementierungen sicherzustellen, werden in Android 11 alle von der HAL zurückgegebenen nicht erfolgreichen Fehlercodes als Programmierfehler behandelt, deren Behebung einen Neustart des HAL-Prozesses erfordert. Hierbei handelt es sich um eine Wiederherstellungsstrategie der letzten Instanz, und es wird erwartet, dass solche Fälle in einem ordnungsgemäß funktionierenden System nicht auftreten.