Wyzwalacz dźwiękiem

Funkcja Sound Trigger umożliwia aplikacjom nasłuchiwanie określonych zdarzeń akustycznych, takich jak słowa kluczowe, przy niskim poborze mocy i z zachowaniem prywatności. Przykładowe przypadki użycia reguły dźwiękowej to Asystent i Odtwarzanie.

Ta strona zawiera ogólny opis architektury Sound Trigger i interfejsu HAL (Hardware Abstraction Layer).

Stos wyzwalania dźwięku

Podsystem Sound Trigger jest zbudowany z warstw, jak pokazano na rysunku 1:

sound_trigger_stack

Rysunek 1. Grupa reguł dźwiękowych

Poniższa lista zawiera bardziej szczegółowy opis poszczególnych warstw na rysunku 1:

  • Warstwa HAL (na zielono) zawiera kod specyficzny dla dostawcy, który implementuje interfejs Sound Trigger HAL (STHAL).

  • SoundTriggerMiddleware (w kolorze żółtym) znajduje się nad interfejsem HAL. Komunikuje się z HAL i odpowiada za funkcje takie jak udostępnianie HAL między różnymi klientami, rejestrowanie, egzekwowanie uprawnień i obsługa zgodności ze starszymi wersjami HAL.

  • System SoundTriggerService (w kolorze niebieskim) znajduje się nad oprogramowaniem pośredniczącym. Ułatwia to integrację z innymi funkcjami systemu, takimi jak telefony i zdarzenia dotyczące baterii. Utrzymuje też bazę danych modeli dźwiękowych, indeksowaną za pomocą unikalnych identyfikatorów.

  • Powyżej warstwy SoundTriggerService znajduje się element (kolor brązowy), który obsługuje funkcje związane z Asystentem i z ogólnymi aplikacjami.

Zadaniem modułu Sound Trigger jest dostarczanie oddzielnych zdarzeń, które reprezentują akustyczne zdarzenia uruchamiające. W większości przypadków pakiet Sound Trigger nie obsługuje dźwięku. Po otrzymaniu zdarzeń aktywatora aplikacje uzyskują dostęp do rzeczywistego strumienia audio, obejmującego czas zdarzeń, otwierając obiekt AudioRecord za pomocą interfejsu Audio. Interfejsy Sound Trigger HAL udostępniają uchwyt z wywołanym zdarzeniem, który jest używany w ramach platformy audio. Ponieważ interfejs HAL Sound Trigger i interfejs HAL Audio są ze sobą połączone, zazwyczaj korzystają z tego samego procesu.

Interfejs Sound Trigger HAL

Interfejs Sound Trigger HAL (STHAL) to część stosu Sound Trigger, która obsługuje rozpoznawanie słów kluczowych i innych dźwięków przez sprzęt. STHAL udostępnia co najmniej jeden moduł z co najmniej jednym algorytmem, który służy do wykrywania określonej klasy dźwięków. Gdy STHAL wykryje pewien bodziec, wysyła zdarzenie do frameworku, a potem przerywa wykrywanie.

Interfejs STHAL jest określony w sekcji /hardware/interfaces/soundtrigger/.

Interfejs ISoundTriggerHw umożliwia uruchamianie w danym momencie co najmniej 1 sesji wykrywania oraz słuchanie zdarzeń akustycznych. Wywołanie funkcji ISoundTriggerHw.getProperties() zwraca strukturę Properties zawierającą opis implementacji i możliwości.

Rysunek 2 przedstawia podstawowy proces konfigurowania sesji:

sthal_state

Rysunek 2. Diagram stanów STHAL

Poniżej znajdziesz szczegółowe omówienie poszczególnych stanów:

  1. Klient HAL wczytuje model za pomocą loadSoundModel() lub loadPhraseSoundModel(). Podany obiekt modelu wskazuje, którego algorytmu wykrywania (silnika) implementacji należy użyć, a także parametry tego algorytmu. Jeśli operacja się powiedzie, te metody zwracają uchwyt, który jest używany do odniesienia do tego modelu w kolejnych wywołaniach.

  2. Gdy model zostanie załadowany, klient HAL wywołuje funkcję startRecognition(), aby rozpocząć wykrywanie. Rozpoznawanie działa w tle do momentu wystąpienia jednego z tych zdarzeń:

    1. W tym modelu został wywołany element stopRecognition().
    2. Wystąpiło wykrycie.
    3. Wykrywanie zostało przerwane z powodu ograniczeń zasobów, na przykład gdy został zainicjowany przypadek użycia o wyższym priorytecie.

    W tych dwóch ostatnich przypadkach zdarzenie rozpoznawania jest wysyłane przez interfejs wywołania zwrotnego zarejestrowany przez klienta HAL podczas wczytywania. We wszystkich przypadkach po wystąpieniu któregoś z tych zdarzeń wykrywanie staje się nieaktywne i nie są już dozwolone żadne wywołania rozpoznawania.

    Ten sam model można uruchomić ponownie w późniejszym czasie. Proces ten można powtarzać tyle razy, ile potrzeba.

  3. Na koniec klient HAL za pomocą funkcji unloadModel() wyładuje nieaktywny model, który nie jest już potrzebny.

Obsługa błędów HAL

Aby zapewnić niezawodne i spójne działanie różnych implementacji sterowników, w Androidzie 11 wszystkie kody błędów zwracane przez HAL są traktowane jako błędy programistyczne, których naprawa wymaga ponownego uruchomienia procesu HAL. Jest to strategia odzyskiwania danych stosowana w ostatniej dekadzie. Oczekujemy, że w prawidłowo działającym systemie takie przypadki nie będą występować.