次の方法で共有


複数の音声アシスタント

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

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

Windows Cortana の実装の詳細については、「 音声ライセンス認証」を参照してください。

音声アクティブ化

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

音声アクティブ化の実装は重要なプロジェクトであり、SoC ベンダーが完了するタスクです。 OEM は、SoC の音声ライセンス認証の実装に関する情報を SoC ベンダーに問い合わせることができます。

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

音声のアクティブ化は、キー フレーズが検出された場合に反応するキーワード スッター (KWS) を利用します。 キー フレーズには、"Hey Contoso" などのキーワードが含まれる場合があります。 キーワード検出 は、ハードウェアまたはソフトウェアによるキーワードの検出を記述します。

キー フレーズは、ステージング されたコマンドとして自分自身 ("Hey Contoso") が発声するか、チェーンコマンド ("Hey Contoso, where is my next meeting?") を作成する音声アクションが続く場合があります。

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

KWS がデバイスを低電力状態から復帰させる場合、ソリューションは Wake-on-Voice (WoV) と呼ばれます。 詳細については、この記事の後半 の「Wake on Voice 」を参照してください。

用語集

この用語集は、音声のアクティブ化に関連する用語をまとめたものです。

任期 例/定義
Staged コマンド 例: Contoso <一時停止して、アシスタントのUIを待って> 天気はどうですか? これは、"2 ショット コマンド" または "キーワード専用" と呼ばれることもあります。
Chained コマンド 例: Contoso さん天気は何ですか? これは"ワンショット コマンド" と呼ばれることもあります。
音声アクティブ化 例: "Hey Contoso" 定義済みのアクティブ化キー フレーズでキーワードが検出されるシナリオ。
Wake-on-Voice (WoV) 画面がオフで低消費電力状態から、画面がオンで最大電力状態へと移行する音声アクティベーションを可能にする技術。
モダン スタンバイからの WoV モダン スタンバイ (S0ix) 画面から全画面表示 (S0) 状態の画面へのウェイクオンボイス。
モダン スタンバイ Windows Low Power Idle インフラストラクチャ - 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 複数の音声エージェント - 複数のエージェントをサポートする HWKWS DDI。
SVA シングル ボイス エージェント - 1 つのエージェントのみをサポートする以前の HWKWS DDI (Cortana)。

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

ハードウェア キーワード スッター (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」 参照してください。

検証

Voice Activation Manager 2 テストを使用して、KSPROPSETID_SoundDetector2 プロパティの HW サポートを検証します。

サンプル コードの概要

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

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

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

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

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

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

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

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

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 クエリ KSPROPERTY_SOUNDDETECTOR_PATTERNS 、イベント検出 OEM アダプターの clsid を取得します。
  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 Detector OEM アダプター インターフェイス

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

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

COM スレッド モデルの要件

OEM の実装では、COM スレッド モデルのいずれかを選択できます。

IEventDetectorOemAdapter

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

メソッド

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

WAVERT の機能強化

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

バッファー サイズ

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

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

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

DEVPKEY_KsAudio_PacketSize_Constraints2

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

IMiniportWaveRTInputStream

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

IMiniportWaveRTOutputStream

WaveRT ミニポートは、必要に応じて、OS からの書き込みの進行状況を通知し、正確なストリーム位置を返すために、このインターフェイスを実装します。 詳細については、「 IMiniportWaveRTOutputStream::SetWritePacketIMiniportWaveRTOutputStream::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. もし、より多くの未読のバッファデータが利用可能であれば、ドライバーは次のいずれかを実行します: i. すぐに、そのデータを WaveRT バッファーの使用可能な領域 (つまり、GetReadPacket から返されたパケットで使用されない領域) に転送し、MoreData に対して true を返し、このルーチンから戻る前にバッファー通知イベントを設定します。 または、ii. 次のパケットを WaveRT バッファーの使用可能な領域にバーストし、MoreData の場合は false を返し、転送が完了したときに後でバッファー イベントを設定するハードウェアをプログラムします。

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

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

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

  6. (2) に移動します。

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

音声で起動

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

この機能を使用すると、デバイスがアイドル状態で画面がオフになっている間、デバイスは常にユーザーの声をリッスンできます。 これは、通常のマイク録音に比べてはるかに少ない電力を使用するリスニングモードによるものです。 WoV では、"Hey Contoso, when's my next appointment" のようなチェーンされた音声フレーズを使用して、ハンズフリーの方法で音声アシスタントからの応答を呼び出すことができます。

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

最新のスタンバイ システムでの検証

システムアイドル状態からの WoV は、AC 電源の Modern Standby Wake on Voice Basic テストHLKDC 電源の Modern Standby Wake on Voice Basic テストを使用して、モダン スタンバイ システムで検証できます。 これらのテストでは、システムにハードウェア キーワード スッター (HW-KWS) があり、Deepest Runtime Idle Platform State (DRIPS) に入ることができ、システム再開の待機時間が 1 秒以下の音声コマンドで Modern Standby から復帰できることを確認します。

ACX と MVA

オーディオ クラス 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ピンを追加するプロセスで使用されます。 関連付けられたコールバックは、パターンの取得、武装解除、およびリセットを処理します。 キーワード スッターの構成を記述する初期化された 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 がストリームブリッジにストリームを自動的に関連付けないようにします。

こちらも参照ください

音声によるアクティブ化