サウンド トリガー

サウンド トリガー機能は、起動ワードなどの特定の音響イベントを省電力かつプライバシーに配慮した方法でリッスンできる機能をアプリに提供します。サウンド トリガーの使用例は、アシスタントと「この曲なに？」です。

このページでは、サウンド トリガー アーキテクチャとその HAL（Hardware Abstraction Layer）インターフェースの概要を説明します。

サウンド トリガー スタック

図 1 に示すように、サウンド トリガー サブシステムはレイヤに組み込まれています。

sound_trigger_stack

図 1: サウンド トリガー スタック

以下に、図 1 の各レイヤについて詳細を説明します。

  • HAL レイヤ（緑色）には、サウンド トリガー HAL（STHAL）インターフェースを実装するベンダー固有のコードが含まれています。

  • SoundTriggerMiddleware（黄色）は HAL インターフェースの上にあります。HAL と通信し、異なるクライアント間での HAL の共有、ロギング、権限の適用、古い HAL バージョンとの互換性の確保などの機能を担当します。

  • SoundTriggerService（青）システムはミドルウェアの上にあります。これにより、電話やバッテリーのイベントなど、他のシステム機能との統合が容易になります。また、一意の ID でインデックス付けされたサウンドモデルのデータベースを維持します。

  • SoundTriggerService レイヤの上にあるスタック（茶色）は、アシスタントと汎用アプリに固有の機能を個別に処理します。

サウンド トリガー スタックの機能は、音響トリガー イベントを表す個別のイベントを配信することです。ほとんどの場合、サウンド トリガー スタックは音声を処理しません。トリガー イベントを受信すると、アプリは、オーディオ フレームワーク経由で AudioRecord オブジェクトを開くことで、イベントの時刻周辺の実際のオーディオ ストリームにアクセスできます。サウンド トリガー HAL API は、オーディオ フレームワークで使用されるトリガーされたイベントにハンドルを提供します。したがって、サウンド トリガー HAL とオーディオ HAL は内部で接続されているため、通常はプロセスを共有します。

サウンド トリガー HAL インターフェース

サウンド トリガー HAL（STHAL）インターフェースは、サウンド トリガー スタックのベンダー固有の部分であり、起動ワードなどの音のハードウェア認識を処理します。STHAL は 1 つ以上のエンジンを提供し、各エンジンは、特定のクラスの音を検出するように設計された異なるアルゴリズムを実行します。STHAL はトリガーを検出すると、フレームワークにイベントを送信してから、検出を停止します。

STHAL インターフェースは /hardware/interfaces/soundtrigger/ で指定されます。

ISoundTriggerHw インターフェースは、特定の時間に 1 つ以上の検出セッションを実行し、音響イベントをリッスンできます。ISoundTriggerHw.getProperties() を呼び出すと、実装の説明と機能を含む Properties 構造が返されます。

セッションを設定する基本的なフローは、図 2 で次のように説明されています。

sthal_state

図 2: STHAL の状態図

次の手順では、各状態について詳しく説明します。

  1. HAL クライアントは loadSoundModel() または loadPhraseSoundModel() を使用してモデルを読み込みます。提供されたモデル オブジェクトは、使用する実装固有の検出アルゴリズム（エンジン）と、このアルゴリズムに適用可能なパラメータを示します。成功すると、これらのメソッドは、後続の呼び出しでこのモデルを参照するために使用するハンドルを返します。

  2. モデルが正常に読み込まれると、HAL クライアントは startRecognition() を呼び出して検出を開始します。次のいずれかのイベントが発生するまで、認識はバックグラウンドで引き続き実行されます。

    1. このモデルで stopRecognition() が呼び出された。
    2. 検出が発生した。
    3. リソースの制約（たとえば、優先度の高いユースケースが開始された場合など）により、検出が中止された。

    最後の 2 つのケースでは、読み込み時に HAL クライアントによって登録されたコールバック インターフェースを介して認識イベントが送信されます。すべての場合において、このようなイベントのいずれかが発生すると検出は非アクティブになり、認識コールバックは許可されなくなります。

    同じモデルを後で再開でき、このプロセスは必要に応じて何回でも繰り返すことができます。

  3. 最後に、不要になった非アクティブなモデルは、HAL クライアントによって unloadModel() を介してアンロードされます。

HAL エラーの処理

ドライバ実装間で動作の信頼性と一貫性を確保するため、Android 11 では、HAL から返された不成功のエラーコードはすべてプログラミング エラーとして扱われ、復旧するには HAL プロセスの再起動が必要になります。これは最終手段の復旧策であり、正常に動作しているシステムではこのような事態は発生しないと考えられます。