サウンドトリガー

サウンドトリガー機能は、ホットワードなどの特定の音響イベントを低電力でプライバシーに配慮した方法でリッスンする機能をアプリに提供します。サウンドトリガーの使用例は、アシスタントと再生中です。

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

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

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

sound_trigger_stack

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

次のリストでは、図1に示されている各レイヤーについて詳しく説明します。

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

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

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

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

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

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

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

STHALインターフェイスは/hardware/interfaces/soundtrigger/ 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プロセスを再起動する必要があります。これは最後の手段である回復戦略であり、適切に機能しているシステムではこのようなケースは発生しないことが予想されます。