サウンド トリガー

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

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

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

図 1 に示すように、サウンド トリガー サブシステムは複数のレイヤに分かれています。

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

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

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

  注: レガシー HAL の実装に関するアダプターとしてではなく、STHAL インターフェースを直接実装することをおすすめします。

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

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

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

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

注: モデルとデータ型はサウンド トリガー サブシステムのフレームワークに対して不透明であるため、アプリと HAL 実装は「隠された契約」を維持することが期待されます。つまり、これらのデータ型の実際のコンテンツ、形式、セマンティクスは合意されたものです。そのため、サウンド トリガーを使用するアプリは、独立したデベロッパーではなく、ベンダー提供であることが想定されています。

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

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

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

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

セッションを設定する基本的なフローを、次の図 2 で説明します。

図 2: STHAL の状態図

各状態についてより詳しく、ステップに分けて説明します。

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

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

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

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

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

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

注: モデルが開始されている場合、HAL クライアントは forceRecognitionEvent() を呼び出して強制認識イベントを生成できます。返されるイベントは通常の認識イベントと似ていますが、ステータス フィールドが FORCED に設定されています。このような認識イベントは、認識を自動的に停止しません。イベントが配信された後も、モデルの状態は実行されたままになります。

HAL エラーの処理

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

注: HAL API のドキュメントでは、こうしたエラーは有効とされていますが、それらのエラーコードがいつどのような状態で返されるか、および想定されるエラー復旧手順がどのようなものであるかについて曖昧な点があります。したがって、Android 11 では、実行時のサウンド トリガー HAL 実装に対して、Android の下位バージョンよりも厳格な基準を定めています。