音声によるアクティブ化

Windows 音声プラットフォームである Cortana は、Cortana やディクテーションなど、Windows 10 のすべての音声エクスペリエンスを強化します。 音声のアクティブ化は、ユーザーが特定の語句 "コルタナさん" と言うことで、さまざまなデバイスの電源状態から音声認識エンジンを呼び出す機能です。音声ライセンス認証テクノロジをサポートするハードウェアを作成するには、この記事の情報を確認してください。

Cortana エンド ユーザー エクスペリエンス

Windows で使用できる音声操作エクスペリエンスを理解するには、次の記事を参照してください。

"コルタナさん" 音声のアクティブ化と "自分の音声の学習" の概要

コルタナさん" 音声によるアクティブ化

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

音声アクティブ化では、定義済みのキー フレーズまたはアクティブ化フレーズを使用して、常に音声入力をリッスンできます。 キー フレーズは、自分で ("コルタナさん") を段階的なコマンドとして発声したり、音声アクション ("コルタナさん、次の会議はどこに行われますか?" など) を続けたりすることができます。これは、チェーンされたコマンドです。

キーワード検出という用語は、ハードウェアまたはソフトウェアによるキーワードの検出を表します。

キーワードのみの アクティブ化は、Cortana キーワードが言われている場合にのみ発生します。Cortana は EarCon サウンドを起動して再生し、リッスン モードに入ったことを示します。

チェーン コマンドは、キーワードの直後にコマンドを発行し ("Hey Cortana, call John")、Cortana を起動して (まだ開始していない場合)、コマンドに従う (John で電話を開始する) 機能を記述します。

この図は、チェーンされたアクティブ化とキーワードのみのアクティブ化を示しています。

Microsoft では、ハードウェア キーワード検出の品質を確保し、ハードウェア キーワード検出が存在しない場合や使用できない場合に Cortana エクスペリエンスを提供するために使用される OS の既定のキーワード スッター (ソフトウェア キーワード スッター) を提供します。

"自分の声を学習する" 機能

"自分の声を学習する" 機能を使用すると、ユーザーは Cortana をトレーニングして自分の固有の音声を認識できます。 これは、ユーザーが [Cortana の設定] 画面で [Cortana さん] と言う方法を確認 するを選択することで実現されます。 その後、ユーザーは慎重に選択された 6 つのフレーズを繰り返し、ユーザーの声の一意の属性を識別するのに十分なさまざまなふりがなパターンを提供します。

音声のアクティブ化が "Learn my voice" と組み合わされている場合、2 つのアルゴリズムが連携して誤ったアクティブ化を減らします。 これは、1 人のユーザーがデバイスでいっぱいの部屋で "コルタナさん" と言う会議室のシナリオで特に重要です。 この機能は、Windows 10 バージョン 1903 以前でのみ使用できます。

音声のアクティブ化は、キー フレーズが検出された場合に反応するキーワード スッター (KWS) を利用します。 KWS がデバイスを低電力状態から復帰させる場合、ソリューションは Wake on Voice (WoV) と呼ばれます。 詳細については、「 Wake on Voice」を参照してください。

用語集

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

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

ハードウェア キーワード スッター (HW KWS) を実装するには、次のタスクを実行します。

• この記事で後述する SYSVAD サンプルに基づいて、カスタム キーワード検出機能を作成します。 これらのメソッドは、 Keyword Detector OEM アダプター インターフェイスで説明されている COM DLL に実装します。
• WAVERT 拡張機能で説明されている WAVE RT 拡張機能を実装します。
• キーワード検出に使用されるカスタム API を記述する INF ファイル エントリを指定します。
  • PKEY_FX_KeywordDetector_StreamEffectClsid
  • PKEY_FX_KeywordDetector_ModeEffectClsid
  • PKEY_FX_KeywordDetector_EndpointEffectClsid
  • PKEY_SFX_KeywordDetector_ProcessingModes_Supported_For_Streaming
  • PKEY_MFX_KeywordDetector_ProcessingModes_Supported_For_Streaming
  • PKEY_EFX_KeywordDetector_ProcessingModes_サポート_ストリーミング用
• オーディオ デバイスの推奨事項のハードウェアに関する推奨事項とテスト ガイダンスを確認します。 この記事では、Microsoft の Speech Platform で使用することを目的としたオーディオ入力デバイスの設計と開発に関するガイダンスと推奨事項を示します。
• ステージング コマンドとチェーン コマンドの両方をサポートします。
• サポートされている Cortana ロケールごとに "Hey コルタナさん" をサポートします。
• API (オーディオ処理オブジェクト) は、次の効果を提供する必要があります。
  • AEC
  • AGC
  • NS
• 音声処理モードの効果は、MFX APO によって報告される必要があります。
• APO では、MFX として形式変換を実行できます。
• APO は次の形式を出力する必要があります。
  • 16 kHz、モノラル、FLOAT。
• 必要に応じて、オーディオ キャプチャ プロセスを強化するためにカスタム API を設計します。 詳細については、「 Windows オーディオ処理オブジェクト」を参照してください。

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

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

HW KWS の AEC 要件

• Windows バージョン 1709 の場合

  • S0スリープ状態（モダンスタンバイ）でのHW KWS WoVをサポートする際にAECは必要ありません。
  • WINDOWS バージョン 1709 では、HW KWS WoV for S0 の動作状態はサポートされていません。

• Windows バージョン 1803 の場合

  • HW KWS WoV for S0 の動作状態がサポートされています。
  • S0 の動作状態に対して HW KWS WoV を有効にするには、APO で AEC がサポートされている必要があります。

サンプル コードの概要

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

https://github.com/Microsoft/Windows-driver-samples/tree/main/audio/sysvad/

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

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

音声起動オーディオスタックのサポート

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

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

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

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

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

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

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

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

キーワードが検出されたときに発生するイベントは 、KSEVENT_SOUNDDETECTOR_MATCHDETECTED イベントです。

操作のシーケンス

システムの起動

1. OS は、サポートされているキーワードの種類を読み取り、その形式のキーワードがあることを確認します。
2. OS は、検出状態変更イベントに登録します。
3. OS はキーワード パターンを設定します。
4. OS は検出器を準備します。

KS イベントを受け取る際

1. ドライバーが検出機能を解除します。
2. OS はキーワード検出の状態を読み取り、返されたデータを解析し、検出されたパターンを決定します。
3. OSは検出機能を再起動します。

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

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

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

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

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

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

キーワードディテクター OEM アダプター インターフェイス

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

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

COM スレッド モデルの要件

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

IKeywordDetectorOemアダプター

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

Methods

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

• IKeywordDetectorOemAdapter::BuildArmingPatternData
• IKeywordDetectorOemAdapter::ComputeAndAddUserModelData
• IKeywordDetectorOemAdapter::GetCapabilities
• IKeywordDetectorOemAdapter::ParseDetectionResultData
• IKeywordDetectorOemAdapter::VerifyUserKeyword

KEYWORDID

KEYWORDID 列挙体は、キーワードのテキスト/関数の語句を識別し、Windows 生体認証サービス アダプターでも使用されます。 詳細については、「生体認証フレームワークの概要 - コア プラットフォーム コンポーネント」を参照してください。

typedef enum  {
  KwInvalid    = 0,
  KwHeyCortana = 1,
  KwSelect     = 2
} KEYWORDID;

KEYWORDSELECTOR

KEYWORDSELECTOR 構造体は、特定のキーワードと言語を一意に選択する ID のセットです。

typedef struct
{
    KEYWORDID KeywordId;
    LANGID LangId;
} KEYWORDSELECTOR;

モデル データの処理

静的ユーザーに依存しないモデル - 通常、OEM DLL には、DLL に組み込まれている静的ユーザーに依存しないモデル データや、DLL に含まれる別のデータ ファイルが含まれます。 GetCapabilities ルーチンによって返されるサポートされるキーワード ID のセットは、このデータに依存します。 たとえば、GetCapabilities によって返されるサポートされているキーワード ID の一覧に KwHeyCortana が含まれている場合、静的ユーザーに依存しないモデル データには、サポートされているすべての言語の "コルタナさん" (またはその翻訳) のデータが含まれます。

動的ユーザー依存モデル - IStream は、ランダム アクセス ストレージ モデルを提供します。 OS は、IKeywordDetectorOemAdapter インターフェイス上の多くのメソッドに IStream インターフェイス ポインターを渡します。 OS は、IStream の実装を、最大 1 MB のデータに対して適切なストレージでバックアップします。

このストレージ内のデータの内容と構造は、OEM によって定義されます。 目的は、OEM DLL によって計算または取得されたユーザー依存モデル データの永続的なストレージを目的としています。

OS は、特にユーザーがキーワードをトレーニングしたことがない場合に、空の IStream でインターフェイス メソッドを呼び出す場合があります。 OS は、ユーザーごとに個別の IStream ストレージを作成します。 つまり、特定の IStream は、1 人のユーザーに対してのみモデル データを格納します。

OEM DLL 開発者は、ユーザーに依存しないデータとユーザー依存データを管理する方法を決定します。 ただし、IStream の外部のどこにもユーザー データを格納しないでください。 1 つの OEM DLL 設計では、現在のメソッドのパラメーターに応じて、IStream と静的ユーザーに依存しないデータへのアクセスを内部的に切り替えます。 別の設計では、各メソッド呼び出しの開始時に IStream をチェックし、静的ユーザーに依存しないデータがまだ存在しない場合は IStream に追加し、残りのメソッドがすべてのモデル データの IStream にのみアクセスできるようにします。

トレーニングおよび操作に関するオーディオ処理

前に説明したように、トレーニング UI フローでは、完全なふりがなの豊富な文がオーディオ ストリームで使用できるようになります。 各文は IKeywordDetectorOemAdapter::VerifyUserKeyword に個別に渡され、予期されるキーワードが含まれており、許容できる品質であることを確認します。 すべての文が UI によって収集および検証されると、 IKeywordDetectorOemAdapter::ComputeAndAddUserModelData への 1 回の呼び出しですべて渡されます。

音声は、音声アクティブ化トレーニングに固有の方法で処理されます。 次の表は、音声アクティブ化トレーニングと通常の音声認識の使用方法の違いをまとめたものです。

キーワード認識システムの概要

次の図は、キーワード認識システムの概要を示しています。

キーワード認識シーケンス図

これらの図では、音声ランタイム モジュールが音声プラットフォームとして表示されています。 前述のように、Windows 音声プラットフォームは、Cortana やディクテーションなど、Windows 10 のすべての音声エクスペリエンスを強化するために使用されます。

起動時に、 IKeywordDetectorOemAdapter::GetCapabilities を使用して機能が収集されます。

後でユーザーが [自分の音声を学習する] を選択すると、トレーニング フローが呼び出されます。

この図では、キーワード検出のためのアーミングプロセスについて説明します。

WAVERT の機能強化

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

バッファー サイズ

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

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

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

DEVPKEY_KsAudio_PacketSize_Constraints

DEVPKEY_KsAudio_PacketSize_Constraints プロパティの値には、物理的なハードウェア制約を記述する KSAUDIO_PACKETSIZE_CONSTRAINTS 構造が含まれています (つまり、WaveRT バッファーからオーディオ ハードウェアにデータを転送する仕組みのため)。 構造体には、任意の信号処理モードに固有の制約を記述する 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() を呼び出して、使用可能なデータに関する情報を取得します。

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

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

   3. 未読のバッファーデータがさらに使用可能な場合、ドライバーは次のいずれかの処理を行います。

      1. そのデータを WaveRT バッファーの使用可能な領域 (つまり、GetReadPacket から返されたパケットで使用されない領域) にすぐに転送し、MoreData に対して true を返し、このルーチンから戻る前にバッファー通知イベントを設定します。 または
      2. 次のパケットを 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) を使用すると、ユーザーが特定のキーワード ("コルタナさん" など) を言うことで、画面オフの低電力状態から画面オンの完全電力状態に移行し、音声認識エンジンを起動してクエリを実行することができます。

この機能を使用すると、画面がオフでデバイスがアイドル状態のときなど、デバイスが低電力状態にある間、デバイスは常にユーザーの音声をリッスンできます。 これは、通常のマイク録音中に見られるより高い電力使用量と比較して低い電力であるリスニングモードを使用して行われます。 低出力の音声認識を使用すると、ユーザーは "コルタナさん" のような定義済みのキー フレーズを言い、その後に "次の予定時" のようなチェーンされた音声フレーズを言って、ハンズフリーの方法で音声を呼び出すことができます。 これは、デバイスが使用中か、画面がオフになっている状態でアイドル状態であるかに関係なく機能します。

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

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

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