Wyzwalacz dźwięku

Funkcja Sound Trigger zapewnia aplikacjom możliwość nasłuchiwania określonych zdarzeń akustycznych, takich jak słowa-klucze, w sposób oszczędzający energię i uwzględniający prywatność. Przykładowe przypadki użycia wyzwalacza dźwiękowego to Asystent i Teraz odtwarzane.

Ta strona zawiera przegląd architektury Sound Trigger i jej interfejsu HAL (Hardware Abstraction Layer).

Stos wyzwalacza dźwiękowego

Podsystem Sound Trigger składa się z warstw, jak pokazano na rysunku 1:

Rysunek 1: Stos wyzwalacza dźwiękowego

Poniższa lista bardziej szczegółowo opisuje każdą warstwę pokazaną 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 pomiędzy różnymi klientami, logowanie, wymuszanie uprawnień i obsługa zgodności ze starszymi wersjami HAL.

• System SoundTriggerService (na niebiesko) znajduje się nad oprogramowaniem pośredniczącym. Ułatwia integrację z innymi funkcjami systemu, takimi jak telefonia i zdarzenia dotyczące baterii. Utrzymuje również bazę danych modeli dźwięków, indeksowanych unikalnymi identyfikatorami.

• Powyżej warstwy SoundTriggerService stos (w kolorze brązowym) osobno obsługuje funkcje specyficzne dla aplikacji Asystent i ogólnych.

Funkcją stosu Sound Trigger jest dostarczanie dyskretnych zdarzeń, które reprezentują akustyczne zdarzenia wyzwalające. W większości przypadków stos Sound Trigger nie obsługuje dźwięku. Po odebraniu zdarzeń wyzwalających aplikacje uzyskują dostęp do rzeczywistego strumienia audio otaczającego czas zdarzeń, otwierając obiekt AudioRecord za pośrednictwem struktury Audio. Interfejsy API Sound Trigger HAL zapewniają uchwyt z wyzwalanym zdarzeniem, który jest używany z Audio Framework. W związku z tym, ponieważ Sound Trigger HAL i Audio HAL są połączone pod maską, zazwyczaj mają wspólny proces.

Interfejs HAL wyzwalania dźwięku

Interfejs Sound Trigger HAL (STHAL) jest specyficzną dla dostawcy częścią stosu Sound Trigger i obsługuje sprzętowe rozpoznawanie słów-kluczy i innych dźwięków. STHAL zapewnia jeden lub więcej silników, z których każdy działa według innego algorytmu zaprojektowanego do wykrywania określonej klasy dźwięków. Gdy STHAL wykryje wyzwalacz, wysyła zdarzenie do platformy, a następnie zatrzymuje wykrywanie.

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

Interfejs ISoundTriggerHw umożliwia uruchomienie jednej lub więcej sesji wykrywania w określonym czasie oraz nasłuchiwanie zdarzeń akustycznych. Wywołanie ISoundTriggerHw.getProperties() zwraca strukturę Properties zawierającą opis i możliwości implementacji.

Podstawowy proces tworzenia sesji wyjaśniono w następujący sposób na rysunku 2:

Rysunek 2: Diagram stanu STHAL

Poniższe kroki opisują każdy stan bardziej szczegółowo:

1. Klient HAL ładuje model za pomocą loadSoundModel() lub loadPhraseSoundModel() . Dostarczony obiekt modelu wskazuje, którego algorytmu detekcji (silnika) specyficznego dla implementacji należy użyć, a także parametry mające zastosowanie do tego algorytmu. Po pomyślnym zakończeniu metody te zwracają uchwyt, który jest używany do odwoływania się do tego modelu w kolejnych wywołaniach.

2. Po pomyślnym załadowaniu modelu klient HAL wywołuje startRecognition() , aby rozpocząć wykrywanie. Rozpoznawanie działa w tle do momentu wystąpienia jednego z następujących zdarzeń:

   1. W tym modelu została wywołana stopRecognition() .
   2. Wystąpiło wykrycie.
   3. Wykrywanie jest przerywane z powodu ograniczeń zasobów, na przykład po zainicjowaniu przypadku użycia o wyższym priorytecie.

   W dwóch ostatnich przypadkach zdarzenie rozpoznawania jest wysyłane za pośrednictwem interfejsu wywołania zwrotnego, który jest rejestrowany przez klienta HAL podczas ładowania. We wszystkich przypadkach po wystąpieniu któregokolwiek z tych zdarzeń wykrywanie staje się nieaktywne i nie są dozwolone żadne wywołania zwrotne rozpoznawania.

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

3. Wreszcie nieaktywny model, który nie jest już potrzebny, jest rozładowywany przez klienta HAL za pomocą unloadModel() .

Obsługa błędów HAL

Aby zapewnić niezawodne i spójne zachowanie między implementacjami sterowników, w systemie Android 11 wszelkie kody błędów, które nie powiodły się, zwrócone z warstwy HAL są traktowane jako błędy programistyczne, których odzyskanie wymaga ponownego uruchomienia procesu HAL. Jest to strategia odzyskiwania ostatniej szansy i oczekuje się, że takie przypadki nie wystąpią w prawidłowo działającym systemie.