複数の音声アシスタント

  • [アーティクル]

複数の音声アシスタント プラットフォームは、Windows の追加の音声アシスタントをサポートします。 これにより、PC などの Windows デバイスや HoloLens などのウェアラブルで他のアシスタントを使用できるようになります。 複数の音声アシスタントは、サポートされている一連のキーワード パターンを使用して、同じデバイスでアクティブにすることができます。

Note

複数の音声アシスタントは、Windows 10 バージョン 1903 以降でサポートされています。

Windows Cortana の実装については、音声によるアクティブ化を参照してください。

音声のアクティブ化

音声アクティブ化は、ユーザーが特定のフレーズを発声することで、さまざまなデバイスの電源状態から音声認識エンジンを呼び出せるようにする機能です。

音声アクティベーションの実装は重要なプロジェクトであり、SoCベンダーが行うタスクです。 OEM は、SoC の音声アクティベーションの実装に関する情報を SoC ベンダーに問い合わせることができます。

音声アクティベーションにより、ユーザーは音声を使用して、アクティブなコンテキスト(つまり、現在画面に表示されているもの)の外部で音声アシスタントエクスペリエンスをすばやく実行できます。 ユーザーは、多くの場合、デバイスを物理的に操作したり触れたりすることなく、エクスペリエンスにすぐにアクセスできることを望んでいます。 Xboxユーザーの場合、これはコントローラーを見つけて接続したくないことが原因である可能性があります。 PC ユーザーの場合、キッチンのコンピューターの場合のように、複数のマウス、タッチ、キーボード操作を実行することなく、エクスペリエンスにすばやくアクセスしたい場合があります。

音声アクティベーションは、キーフレーズが検出された場合に反応するキーワードスポッター(KWS)によって強化されます。 キー フレーズには、"Hey Contoso" などのキーワードが含まれる場合があります。キーワード検出は、ハードウェアまたはソフトウェアによるキーワードの検出を表します。

キー フレーズは、ステージングされたコマンドとして単独で発声することも ("Hey Contoso" )、チェーンされたコマンドを構成する音声操作 ("Hey Contoso、次の会議はどこですか?" ) が続く場合もあります。

Microsoft では、ハードウェア キーワード検出が使用できない場合に音声アシスタント エクスペリエンスを提供するために、OS の既定のキーワード スポッター (ソフトウェア キーワード スポッター) を提供しています。 これは現在 Cortana で使用できますが、2 段階のキーワード検出を行うために他の音声アシスタントをオンボードするには、追加の Microsoft 構成が必要になる場合があります。 詳細については、にお問い合わせくださいAskMVA@Microsoft.com。

KWS がデバイスを低電力状態からウェイクアップする場合、その解決策は Wake-on-Voice (WoV) と呼ばれます。 詳細については、この記事で後述するウェイクオンボイスを参照してください。

用語集

この用語集は、音声アクティベーションに関連する用語をまとめたものです。

用語 例/定義
ステージングされたコマンド 例：Contoso 、<一時停止して、アシスタント UI> を待ちます 天気は? これは、"2 ショット コマンド" または "キーワードのみ" と呼ばれることもあります
連鎖コマンド 例：こんにちは、Contoso 天気はどうですか? これは"ワンショットコマンド"と呼ばれることもあります。
音声のアクティブ化 例："Hey Contoso" 定義済みのアクティブ化キー フレーズでキーワードが検出されるシナリオ。
ウェイクオンボイス (WoV) 画面オフの低電力状態からフルパワー状態の画面への音声起動を可能にするテクノロジー。
モダン スタンバイからの WoV モダン スタンバイ (S0ix) 画面オフ状態からフルパワー (S0) 状態への Wake-on-Voice 。
モダン スタンバイ Windows 低電力アイドル インフラストラクチャ - Windows 10 のコネクト スタンバイ (CS) の後継。 モダン スタンバイの最初の状態は、画面がオフのときです。 最も深いスリープ状態は、DRIPS/回復性にあるときです。 詳細については、モダン スタンバイを参照してください。
KWS キーワード スポッター – "Hey Contoso" の検出を提供するアルゴリズム。
SW KWS ソフトウェア キーワード スポッター – ホスト (CPU) 上で実行される KWS の実装。 "コルタナさん" の場合、SW KWS は Windows の一部として含まれています。
HW KWS ハードウェア キーワード スポッター – ハードウェア上でオフロードされて実行される KWS の実装。
バーストバッファ KWS 検出をトリガーしたすべてのオーディオが含まれるように、KWS 検出イベントでバーストできる PCM データを格納するために使用される循環バッファー。
イベント検出器 OEM アダプター Windows 音声アシスタント スタックとドライバーの間の仲介役として機能するユーザー モード コンポーネント。
モデル KWS アルゴリズムで使用される音響モデル データ ファイル。 データファイルは静的です。 モデルはローカライズされ、ロケールごとに 1 つずつ表示されます。
MVA Multiple Voice Agent - 複数のエージェントをサポートする HWKWS DDI。
SVA 単一の音声エージェント - 1 つのエージェント (Cortana) のみをサポートする以前の HWKWS DDI。

ハードウェアキーワードスポッターの統合

ハードウェア キーワード スポッター (HW KWS) を実装するには、SoC ベンダーは次のタスクを完了する必要があります。

ハードウェア オフロード キーワード スポッター (HW KWS) WoV の要件

  • HW KWS WoV は、S0 動作状態と S0 スリープ状態 (モダン スタンバイとも呼ばれます) でサポートされます。
  • HW KWS WoV は S3 からはサポートされていません。

AEC

AECは、バーストオーディオのキャプチャ時にDSPによって実行することも、ソフトウェアAPOを介して後で実行することもできます。 KWS バースト データを使用してソフトウェア AEC を実行するには、バースト データがキャプチャされた時点からの対応するループバック オーディオが必要です。 これを行うために、ループバックオーディオをバーストオーディオデータにインターリーブするバースト出力用のカスタムオーディオ形式が作成されました。

Windows バージョン 20H1 以降、Microsoft AEC APO はこのインターリーブ形式を認識し、それを使用して AEC を実行できます。 詳細については、KSPROPERTY_INTERLEAVEDAUDIO_FORMATINFORMATIONを参照してください。

検証

音声アクティベーションマネージャー 2 テストを使用して、KSPROPSETID_SoundDetector2プロパティーの HW サポートを検証します。

サンプルコードの概要

音声アクティブ化を実装するオーディオ ドライバーのサンプル コードは、SYSVAD 仮想オーディオ アダプター サンプルの一部として GitHub にあります。 このコードを出発点として使用することをお勧めします。

SYSVAD サンプル オーディオ ドライバーの詳細については、サンプル オーディオ ドライバーを参照してください。

キーワード認識システム情報

音声アクティベーション オーディオ スタックのサポート

音声アクティブ化を有効にするためのオーディオ スタック外部インターフェイスは、音声プラットフォームとオーディオ ドライバーの通信パイプラインとして機能します。 外部インターフェイスは 3 つの部分に分かれています。

  • イベント ディテクター デバイス ドライバー インターフェイス (DDI)。 イベントディテクターデバイスドライバーインターフェースは、HW キーワードスポッター (KWS) の構成と準備を担当します。 また、ドライバーが検出イベントをシステムに通知するためにも使用されます。
  • IEvent検出器OEM アダプター DLL。 この DLL は、キーワードの検出を支援するために OS で使用するドライバー固有の不透明なデータを適応させる COM インターフェイスを実装します。
  • WaveRT の機能強化. この機能強化により、オーディオ ドライバーは、キーワード検出からバッファーに格納されたオーディオ データをバースト ストリーミングできます。

オーディオ エンドポイントのプロパティ

オーディオ エンドポイント グラフの構築は正常に行われます。 グラフは、リアルタイムキャプチャよりも高速に処理できるように準備されています。 キャプチャされたバッファーのタイムスタンプは真実のままです。 具体的には、タイムスタンプは、過去にキャプチャされてバッファリングされ、現在バーストしているデータを正しく反映します。

Bluetoothバイパスオーディオストリーミングの理論

ドライバーは、通常どおり、キャプチャ デバイスの KS フィルターを公開します。 このフィルターは、検出イベントを構成、有効化、および通知するためのいくつかの KS プロパティと KS イベントをサポートします。 このフィルターには、キーワード スポッター (KWS) ピンとして識別される追加のピン ファクトリも含まれています。 このピンは、キーワード スポッターからオーディオをストリーミングするために使用されます。

プロパティは次のとおりです：KSPROPSETID_SoundDetector2

すべてのKSPROPSETID_SoundDetector2プロパティは、KSSOUNDDETECTORPROPERTYデータ構造体で呼び出されます。 このデータ構造には、KSPROPERTY と、武装、リセット、検出などのキーワードのイベント ID が含まれています。

  • サポートされているキーワードの種類 - KSPROPERTY_SOUNDDETECTOR_PATTERNS。 このプロパティは、検出されるキーワードを構成するためにオペレーティング システムによって設定されます。
  • キーワード パターン GUID の一覧 - KSPROPERTY_SOUNDDETECTOR_SUPPORTEDPATTERNS。 このプロパティは、サポートされているパターンの種類を識別する GUID の一覧を取得するために使用されます。
  • 武装 - KSPROPERTY_SOUNDDETECTOR_ARMED。 この読み取り/書き込みプロパティは、ディテクターが準備されているかどうかを示す単純なブール状態です。 OS は、キーワード検出機能を有効にするようにこれを設定します。 OS はこれをクリアして解除できます。 ドライバーは、キーワード パターンが設定されたとき、およびキーワードが検出された後に、これを自動的にクリアします。 (OS はリアームする必要があります。
  • 一致結果 - KSPROPERTY_SOUNDDETECTOR_RESETは、起動時にサウンドディテクターをリセットするために使用されます。

キーワード検出時に、KSNOTIFICATIONID_SoundDetectorを含むPNP通知が送信されます。 注: これは KSEvent ではなく、ペイロードと共に IoReportTargetDeviceChangeAsynchronous を介して送信される PNP イベントです。

KSNOTIFICATIONID_SoundDetectorは、次に示すように ksmedia.h で定義されています。

// The payload of this notification is a SOUNDDETECTOR_PATTERNHEADER
#define STATIC_KSNOTIFICATIONID_SoundDetector\
    0x6389d844, 0xbb32, 0x4c4c, 0xa8, 0x2, 0xf4, 0xb4, 0xb7, 0x7a, 0xfe, 0xad
DEFINE_GUIDSTRUCT("6389D844-BB32-4C4C-A802-F4B4B77AFEAD", KSNOTIFICATIONID_SoundDetector);
#define KSNOTIFICATIONID_SoundDetector DEFINE_GUIDNAMED(KSNOTIFICATIONID_SoundDetector)

操作のシーケンス

システムの起動

  1. OS は、以前のディテクタの状態をクリアするKSPROPERTY_SOUNDDETECTOR_RESETを送信し、すべてのディテクタを武装解除にリセットし、以前のパターン セットをクリアします。
  2. OS は、イベント検出機能 OEM アダプターの clsid を取得するためにKSPROPERTY_SOUNDDETECTOR_PATTERNSクエリを実行します。
  3. OS は、イベント ディテクター OEM アダプターを使用して、サポートされているキーワードと言語の一覧を取得します。
  4. OS は、ドライバーによって送信されるカスタム PNP 通知に登録します
  5. OS は、必要なキーワード パターンを設定します。
  6. OS が検出器を作動させる

内部ドライバとハードウェアの動作

検出器が武装している間、ハードウェアはオーディオデータを連続的にキャプチャし、小さなFIFOバッファにバッファリングすることができます。 (この FIFO バッファーのサイズは、このドキュメント以外の要件によって決まりますが、通常は数百ミリ秒から数秒になる場合があります。)検出アルゴリズムは、このバッファを通過するデータストリーミングに対して動作します。 ドライバとハードウェアの設計は、武装している間は、キーワードが検出されるまで、ドライバとハードウェアの間に相互作用がなく、"アプリケーション" プロセッサへの割り込みも行われないようなものです。 これにより、他のアクティビティがない場合に、システムはより低い電力状態に到達できます。

ハードウェアがキーワードを検出すると、割り込みが生成されます。 ドライバーが割り込みを処理するのを待っている間、ハードウェアはオーディオをバッファーにキャプチャし続け、キーワードが失われた後のデータがバッファリング制限内で行われないようにします。

キーワードのタイムスタンプ

キーワードを検出した後、すべての音声アクティベーション ソリューションは、キーワードの開始の 1.6 秒前を含め、すべての音声キーワードをバッファリングする必要があります。 オーディオ ドライバーは、ストリーム内のキー フレーズの開始と終了を識別するタイムスタンプを提供する必要があります。

キーワードの開始/終了タイムスタンプをサポートするために、DSPソフトウェアはDSPクロックに基づいて内部的にイベントのタイムスタンプを取得する必要があります。 キーワードが検出されると、DSP ソフトウェアはドライバーと対話して KS イベントを準備します。 ドライバーと DSP ソフトウェアは、DSP タイムスタンプを Windows パフォーマンス カウンター値にマップする必要があります。 これを行う方法は、ハードウェア設計に固有です。 考えられる解決策の 1 つは、ドライバーが現在のパフォーマンス カウンターを読み取り、現在の DSP タイムスタンプを照会し、現在のパフォーマンス カウンターを再度読み取り、パフォーマンス カウンターと DSP 時間の相関関係を推定することです。 その後、相関関係が与えられると、ドライバーはキーワード DSP タイムスタンプを Windows パフォーマンス カウンターのタイムスタンプにマップできます。

IEvent 検出器 OEM アダプター インターフェイス

OEM は、OS とドライバーの間の仲介役として機能する COM オブジェクトの実装を提供し、KSPROPERTY_SOUNDDETECTOR_PATTERNSとKSPROPERTY_SOUNDDETECTOR_MATCHRESULTを介してオーディオ ドライバーに書き込まれ読み取られる不透明なデータの計算または解析を支援します。

COM オブジェクトの CLSID は、KSPROPERTY_SOUNDDETECTOR_SUPPORTEDPATTERNSによって返されるディテクター パターン タイプの GUID です。 OS は、パターンの種類 GUID を渡して CoCreateInstance を呼び出し、キーワード パターンの種類と互換性のある適切な COM オブジェクトをインスタンス化し、オブジェクトの IEventDetectorOemAdapter インターフェイスのメソッドを呼び出します。

COM スレッド モデルの要件

OEM の実装では、任意の COM スレッド モデルを選択できます。

IEventDetectorOemAdapter

インターフェイスの設計では、オブジェクトの実装をステートレスに保とうとします。 言い換えれば、実装では、メソッド呼び出し間に状態を格納する必要はありません。 実際、内部 C++ クラスでは、一般的な COM オブジェクトの実装に必要なメンバー変数以外のメンバー変数は必要ない可能性があります。

メソッド

次のメソッドを実装します。

WAVERTの機能強化

ミニポート インターフェイスは、WaveRT ミニポート ドライバーによって実装されるように定義されています。 これらのインターフェイスは、オーディオ ドライバーを簡略化したり、OS オーディオ パイプラインのパフォーマンスと信頼性を向上させたり、新しいシナリオをサポートしたりするための方法を提供します。 PnP デバイス インターフェイス プロパティが定義され、ドライバーはバッファー サイズ制約の静的な式を OS に提供できます。

バッファサイズ

ドライバーは、OS、ドライバー、ハードウェア間でオーディオ データを移動するときに、さまざまな制約の下で動作します。 これらの制約は、メモリとハードウェア間でデータを移動する物理的なハードウェア トランスポート、および/またはハードウェアまたは関連する DSP 内の信号処理モジュールが原因である可能性があります。

HW-KWS ソリューションは、少なくとも 100msから最大 200msのオーディオ キャプチャ サイズをサポートする必要があります。

ドライバーは、KS ストリーミング ピンを持つ KS フィルターの KSCATEGORY_AUDIO PnP デバイス インターフェイスで DEVPKEY_KsAudio_PacketSize_Constraints2 デバイス プロパティを設定することで、バッファー サイズの制約を表します。 このプロパティは、KS フィルター インターフェイスが有効になっている間、有効で安定した状態を維持する必要があります。 OS は、ドライバーへのハンドルを開いてドライバーを呼び出すことなく、いつでもこの値を読み取ることができます。

DEVPKEY_KsAudio_PacketSize_Constraints2

DEVPKEY_KsAudio_PacketSize_Constraints2 プロパティ値には、物理的なハードウェアの制約 (つまり、WaveRT バッファーからオーディオ ハードウェアにデータを転送するメカニズムによる) を記述するKSAUDIO_PACKETSIZE_CONSTRAINTS2 構造が含まれています。 構造体には、任意の信号処理モードに固有の制約を記述する 0 個以上のKSAUDIO_PACKETSIZE_PROCESSINGMODE_CONSTRAINT構造体の配列が含まれます。 ドライバーは、 PcRegisterSubdevice を呼び出す前に、またはストリーミング ピンの KS フィルター インターフェイスを有効にする前に、このプロパティを設定します。

IMiniportWaveRTInputStream

ドライバーは、ドライバーから OS へのオーディオ データフローをより適切に調整するために、このインターフェイスを実装します。 このインターフェイスがキャプチャ ストリームで使用できる場合、OS はこのインターフェイスのメソッドを使用して WaveRT バッファー内のデータにアクセスします。 詳細については、IMiniportWaveRTInputStream::GetReadPacketを参照してください

IMiniportWaveRTOutputStream

WaveRT ミニポートは、必要に応じてこのインターフェイスを実装して、OS からの書き込みの進行状況を通知し、正確なストリーム位置を返します。 詳細については、IMiniportWaveRTOutputStream::SetWritePacket、IMiniportWaveRTOutputStream::GetOutputStreamPresentationPositionとIMiniportWaveRTOutputStream::GetPacketCountを参照してください。

パフォーマンス カウンターのタイムスタンプ

いくつかのドライバー ルーチンは、サンプルがデバイスによってキャプチャまたは提示された時刻を反映した Windows パフォーマンス カウンターのタイムスタンプを返します。

複雑なDSPパイプラインと信号処理を備えたデバイスでは、正確なタイムスタンプを計算することが困難な場合があるため、慎重に行う必要があります。 タイムスタンプは、サンプルが OS との間で DSP に転送された時刻を単純に反映するべきではありません。

  • DSP内では、DSPの内部ウォールクロックを使用してサンプルのタイムスタンプを追跡します。
  • ドライバーと DSP の間で、Windows パフォーマンス カウンターと DSP ウォール クロックの間の相関関係を計算します。 この手順は、非常に単純なもの(ただし、精度は低い)から、かなり複雑なものや斬新なもの(ただし、より正確)までさまざまです。
  • 信号処理アルゴリズム、パイプライン、またはハードウェアの転送による一定の遅延は、特に考慮されていない限り、考慮に入れます。

バースト読み取り動作

このセクションでは、バースト読み取りの OS とドライバーの相互作用について説明します。 バースト読み取りは、ドライバーが IMiniportWaveRTInputStream::GetReadPacket 関数を含むパケット ベースのストリーミング WaveRT モデルをサポートしている限り、音声アクティブ化シナリオの外部で発生する可能性があります。

バースト読み取りシナリオの 2 つの例について説明します。 1 つのシナリオでは、ミニポートがピン カテゴリ KSNODETYPE_AUDIO_KEYWORDDETECTORを持つピンをサポートしている場合、ドライバーはキーワードが検出されたときにデータのキャプチャと内部バッファリングを開始します。 別のシナリオでは、OS が IMiniportWaveRTInputStream::GetReadPacket を呼び出すことによって十分な速度でデータを読み取っていない場合、ドライバーは必要に応じて WaveRT バッファーの外部にデータを内部的にバッファーできます。

KSSTATE_RUN に移行する前にキャプチャされたデータをバーストするには、ドライバーは、バッファーされたキャプチャ データと共に正確なサンプル タイムスタンプ情報を保持する必要があります。 タイムスタンプは、キャプチャされたサンプルのサンプリング瞬間を識別します。

  1. ストリームが KSSTATE_RUN に切り替わると、ドライバーは既に使用可能なデータがあるため、バッファー通知イベントをすぐに設定します。

  2. このイベントで、OS は GetReadPacket() を呼び出して、使用可能なデータに関する情報を取得します。

    a. ドライバーは、有効なキャプチャ データのパケット番号 (KSSTATE_STOP から KSSTATE_RUN への移行後の最初のパケットの場合は 0) を返し、そこから OS は WaveRT バッファー内のパケット位置と、ストリームの開始を基準としたパケット位置を派生させることができます。

    b. また、ドライバーは、パケット内の最初のサンプルのサンプリング瞬間に対応するパフォーマンス カウンター値を返します。 このパフォーマンス カウンター値は、ハードウェアまたはドライバー内 (WaveRT バッファーの外部) でバッファーされているキャプチャ データの量に応じて、比較的古い場合があることに注意してください。

    c. 使用可能な未読バッファリングデータがさらにある場合、ドライバは次のいずれかを行います。 そのデータを WaveRT バッファーの使用可能な領域 (つまり、GetReadPacket から返されたパケットで使用されていない領域) にすぐに転送し、MoreData に対して 真実 を返し、このルーチンから戻る前にバッファー通知イベントを設定します。 または、ii. 次のパケットを WaveRT バッファーの使用可能な領域にバーストするようにハードウェアをプログラムし、MoreData に対して 間違い を返し、後で転送の完了時にバッファー イベントを設定します。

  3. OS は、GetReadPacket() によって返される情報を使用して、WaveRT バッファーからデータを読み取ります。

  4. OS は、次のバッファー通知イベントを待機します。 ドライバーが手順 (2c) でバッファー通知を設定した場合、待機はすぐに終了する可能性があります。

  5. ドライバーが手順 (2c) でイベントをすぐに設定しなかった場合、ドライバーは、キャプチャされたデータを WaveRT バッファーに転送し、OS が読み取れるようにした後にイベントを設定します

  6. (2)に進みます。

KSNODETYPE_AUDIO_KEYWORDDETECTORキーワード検出器ピンの場合、ドライバーは少なくとも5000msのオーディオデータに十分な内部バーストバッファリングを割り当てる必要があります。 バッファーがオーバーフローする前に OS がピンにストリームを作成できない場合、ドライバーは内部バッファリング アクティビティを終了し、関連付けられているリソースを解放する可能性があります。

ウェイクオンボイス

Wake-on-Voice (WoV) を使用すると、ユーザーは "Hey Contoso" などの特定のキーワードを発声することで、低電力状態から画面オンのフル電力状態まで音声認識エンジンをアクティブ化してクエリを実行できます。

この機能を使用すると、デバイスがアイドル状態で画面がオフになっている間も、デバイスは常にユーザーの音声をリッスンできます。 これは、通常のマイク録音に比べて消費電力がはるかに少ないリスニングモードによるものです。 WoV では、"Contoso さん、次の予定はいつですか" のような連鎖した音声フレーズを使用して、音声アシスタントからの応答をハンズフリーで呼び出すことができます。

オーディオ スタックは、ウェイク データ (話者 ID、キーワード トリガー、信頼度に関するコンテキスト情報) を通信し、キーワードが検出されたことを関心のあるクライアントに通知する役割を担います。

モダン スタンバイ システムでの検証

システムアイドル状態からの WoV は、HLK の AC 電源のモダン スタンバイ ウェイク オン ボイスの基本テストおよび DC 電源のモダン スタンバイ ウェイク オン ボイスの基本テストを使用したモダン スタンバイ システムで検証できます。 これらのテストでは、システムにハードウェア キーワード スポッター (HW-KWS) があり、最も深いランタイム アイドル プラットフォーム状態 (DRIPS) に入ることができ、システム再開待機時間が 1 秒以下の音声コマンドでモダン スタンバイからスリープ解除できることを確認します。

ACX と MVA

Audio Class eXtension (ACX) は、オーディオ ドメインの Windows Driver Framework (WDF) クラス拡張機能を定義します。 ACX の詳細については、「ACX オーディオ クラス拡張機能の概要」および「ACX オブジェクトの概要」を参照してください。 このセクションでは、ACX を使用して MVA を実装する方法について説明します。

ACX は、キーワード スポッターに同じ KS インフラストラクチャを使用し、ドライバーの実装を簡略化するための抽象化レイヤーを追加します。 ACX では、上記のように同じ OEM DLL が使用され、変更されません。 ACX と Portcls の両方に IEventDetectorOEMAdapter インターフェイスが必要であり、OEM アダプターの 2 つの実装に違いはありません。

AcxKeywordSpotterCreate 関数は、回路デバイス オブジェクトの親に関連付けられる ACX キーワード スポッター不透明オブジェクト (ACXKEYWORDSPOTTER) を作成するために使用されます。

ACXKEYWORDSPOTTER オブジェクトを使用して、すべての KSPROPERTY_SOUNDDETECTOR 呼び出しを置き換え、KWS の実装を簡素化します。 これは、ACX回路にKWS素子とKWSピンを追加するプロセスで使用されます。 関連するコールバックは、パターンの取得、武装、武装解除、リセットを処理します。 これは、キーワード spotter の構成を記述する初期化された ACX_KEYWORDSPOTTER_CONFIG 構造体を使用します。

ACX_KEYWORDSPOTTER_CONFIG構造体は、次のコールバックを定義するACX_KEYWORDSPOTTER_CALLBACKS構造体を受け取ります。

EvtAcxKeywordSpotterRetrieveArm - ACX_KEYWORDSPOTTER_RETRIEVE_ARM コールバック。

EvtAcxKeywordSpotterAssignArm - ACX_KEYWORDSPOTTER_ASSIGN_ARMコールバック。

EvtAcxKeywordSpotterAssignPatterns - ACX_KEYWORDSPOTTER_ASSIGN_PATTERNSコールバック。

EvtAcxKeywordSpotterAssignReset - ACX_KEYWORDSPOTTER_ASSIGN_RESET コールバック。

ACX PNP イベント

ACX PNP イベントが KSNOTIFICATIONID_SoundDetector に置き換わり、検出通知イベントが簡素化されます。 ACX_PNPEVENT_CONFIG_INIT 関数は、ACX_PNPEVENT_CONFIG構造体を初期化します。 この関数では入力は使用されません。

ACX KWS サンプルコード

ACX KWS サンプル コードは、コールバックの初期化、キーワード要素、キーワード スポッターの作成を示しています。

{
    NTSTATUS                        status;
    WDF_OBJECT_ATTRIBUTES           attributes;
    ACX_KEYWORDSPOTTER_CALLBACKS    keywordSpotterCallbacks;
    ACX_KEYWORDSPOTTER_CONFIG       keywordSpotterCfg;
    PCODEC_KEYWORDSPOTTER_CONTEXT   keywordSpotterCtx;
    ACX_PNPEVENT_CONFIG             keywordEventCfg;
    ACXPNPEVENT                     keywordEvent;

    PAGED_CODE();

    ACX_KEYWORDSPOTTER_CALLBACKS_INIT(&keywordSpotterCallbacks);
    keywordSpotterCallbacks.EvtAcxKeywordSpotterRetrieveArm = CodecC_EvtAcxKeywordSpotterRetrieveArm;
    keywordSpotterCallbacks.EvtAcxKeywordSpotterAssignArm = CodecC_EvtAcxKeywordSpotterAssignArm;
    keywordSpotterCallbacks.EvtAcxKeywordSpotterAssignPatterns = CodecC_EvtAcxKeywordSpotterAssignPatterns;
    keywordSpotterCallbacks.EvtAcxKeywordSpotterAssignReset = CodecC_EvtAcxKeywordSpotterAssignReset;
    
    ACX_KEYWORDSPOTTER_CONFIG_INIT(&keywordSpotterCfg);
    keywordSpotterCfg.Pattern = &CONTOSO_KEYWORDCONFIGURATION_IDENTIFIER2;
    keywordSpotterCfg.Callbacks = &keywordSpotterCallbacks;
    
    WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE(&attributes, CODEC_KEYWORDSPOTTER_CONTEXT);
    attributes.ParentObject = Circuit;

次に、AcxKeywordSpotterCreate 関数を使用して、ACX キーワード スポッター オブジェクトを作成し、既存の回路に関連付けます。

    status = AcxKeywordSpotterCreate(Circuit, &attributes, &keywordSpotterCfg, Element);
    if (!NT_SUCCESS(status))
    {
        ASSERT(FALSE);
        goto exit;
    }

次に、キーワード スポッター コンテキストが決定され、NonPagedPoolNx メモリに KeywordDetector が作成されます。

    
    keywordSpotterCtx = GetCodecKeywordSpotterContext(*Element);
    ASSERT(keywordSpotterCtx);
    
    keywordSpotterCtx->KeywordDetector = (PVOID) new(NonPagedPoolNx, DRIVER_TAG) CKeywordDetector();
    if (keywordSpotterCtx->KeywordDetector == NULL)
    {
        status = STATUS_INSUFFICIENT_RESOURCES;
        ASSERT(FALSE);
        goto exit;
    }

このサンプル コードでは、コンテキストに追加される CKeywordDetector クラスは、サンプル ドライバー内のキーワード スポットをシミュレートする実装例としてのみ提供されています。 CKeywordDetector クラスは、ACX フレームワークの一部でも、ACX での MVA の実装の必須部分でもありませんが、実際のキーワード スポッターを開発するための良い出発点となる可能性があります。

最後に、ACX PnPイベントが設定され、作成されます。

   
    ACX_PNPEVENT_CONFIG_INIT(&keywordEventCfg);
    
    WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE(&attributes, CODEC_PNPEVENT_CONTEXT);
    attributes.ParentObject = *Element;
    status = AcxPnpEventCreate(Device, *Element, &attributes, &keywordEventCfg, &keywordEvent);
    if (!NT_SUCCESS(status))
    {
        ASSERT(FALSE);
        goto exit;
    }

    keywordSpotterCtx->Event = keywordEvent;

    //
    // Done. 
    //
    status = STATUS_SUCCESS;

}

KWSを含む複雑なピン動作を持つ回路

ホスト エンジンや KWS を使用する回線など、複雑なピン動作を持つ回線の場合、ドライバーは ACX を無効にしてストリーム ブリッジ処理を実行しないようにし、代わりにインモードのないストリーム ブリッジを作成する必要があります。 このアプローチにより、ACXはストリームをストリームブリッジに自動的に関連付けなくなります。

関連項目

音声のアクティブ化