Wyzwalacz dźwiękiem

Funkcja Wyzwalacz dźwięku sprawia, że aplikacje mogą nasłuchiwać określonych zdarzeń akustycznych, takich jak słowa-klucze, w sposób, który nie wymaga dużo pracy i jest chroniony prywatności. Przykładowe zastosowania reguły dźwiękowej to Asystent i Co jest grane.

Na tej stronie znajdziesz omówienie architektury aktywatora dźwięku i jej interfejsu HAL (Hardware Abstraction Layer).

Stos wyzwalania dźwięku

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

stos_reguły_dźwiękowej

Rysunek 1. Stos wyzwalania dźwięku

Poniższa lista bardziej szczegółowo opisuje każdą warstwę przedstawioną na rys. 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 integrację z innymi funkcjami systemu, takimi jak telefony i zdarzenia związane z baterią. 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 dotyczące Asystenta i ogólnych aplikacji.

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ń aktywujących aplikacje uzyskują dostęp do rzeczywistego strumienia audio, obejmującego czas trwania zdarzeń, otwierając obiekt AudioRecord za pomocą interfejsu Audio. Interfejsy Sound Trigger HAL API udostępniają uchwyt z wywoływanym zdarzeniem, które jest używane z platformą 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 STHAL komponentu aktywującego dźwięk to specyficzna dla dostawcy część stosu aktywującego dźwięk i obsługuje sprzętowe rozpoznawanie słów-kluczy i innych dźwięków. 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 działanie co najmniej 1 sesji wykrywania w danym momencie i nasłuchiwanie 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óry algorytm wykrywania (silnik) specyficzny dla 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 wskazywania tego modelu w kolejnych wywołaniach.

  2. Po załadowaniu modelu 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 2 ostatnich przypadkach zdarzenie rozpoznawania jest wysyłane przez interfejs wywołania zwrotnego, który jest 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 między implementacjami sterowników, w Androidzie 11 wszelkie kody błędów z błędem HAL, które nie zakończyły się powodzeniem, są traktowane jako błędy programowania, a odzyskiwanie 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ć.