多語音助理平台支援 Windows 中的其他語音助理。 這允許在 Windows 設備上使用其他助手，例如 PC 和穿戴式裝置，例如 HoloLens。 多個語音助理可以使用一組支援的關鍵字模式在同一裝置上處於活動狀態。
備註
從 Windows 10 版本 1903 開始支援多個語音助理。
如需實作 Windows Cortana 的相關資訊，請參閱 語音啟用。
語音啟用
語音啟動是一項功能，可讓使用者透過說出特定片語，從各種裝置電源狀態呼叫語音辨識引擎。
實作語音啟用是一個重要的專案，而且是由SoC廠商完成的工作。 OEM 可以連絡其 SoC 廠商，以取得其 SoC 實作語音啟用的相關信息。
語音激活允許用戶使用語音在其活動上下文（即當前屏幕上的內容）之外快速參與語音助手體驗。 使用者通常希望能夠立即存取體驗，而無需與裝置進行實體互動或觸摸裝置。 對於 Xbox 用戶來說，這可能是因為不想找到並連接控制器。 對於 PC 用戶來說，他們可能希望快速訪問體驗，而不必執行多個鼠標、觸摸和/或鍵盤操作，就像廚房中的計算機一樣。
語音啟用是由關鍵詞 Spotter （KWS） 提供，當偵測到關鍵片語時會做出反應。 關鍵片語可能包含關鍵詞，例如「嘿 Contoso」。 關鍵字偵測 描述硬體或軟體偵測關鍵字。
關鍵片語可以單獨使用 (“Hey Contoso”) 作為觸發指令，或者後續加上一段語音行動來構成連鎖命令 (“Hey Contoso，我的下一個會議在哪裡？”)
Microsoft 提供 OS 預設關鍵字偵測器 （軟體關鍵字偵測器） ，以在硬體關鍵字偵測無法使用的情況下提供語音助理體驗。 雖然這目前可用於 Cortana，但可能需要額外的 Microsoft 配置才能加入其他語音助手以執行兩階段關鍵字檢測。 欲了解更多信息，請聯繫 AskMVA@Microsoft.com。
如果 KWS 要將裝置從低電量狀態喚醒，則該解決方案稱為語音喚醒 （WoV）。 如需詳細資訊，請參閱本文稍後的 語音喚醒 。
術語詞彙表
此詞彙摘要說明與語音啟用相關的詞彙。
| 術語 | 範例/定義 |
|---|---|
| 階段性命令 | 範例：嗨 Contoso <暫停，等待助理 UI> 現在的天氣怎麼樣？ 這有時被稱為「兩步驟命令」或「僅限關鍵字」。 |
| 鏈結命令 | 範例：嘿 Contoso 天氣怎麼樣？ 這有時稱為「一次性命令」。 |
| 語音啟用 | 範例：「Hey Contoso」在預先定義的啟用關鍵詞組中偵測到關鍵字的案例。 |
| 語音喚醒 （WoV） | 可從螢幕關閉、低功率狀態到螢幕全功率狀態進行語音啟動的技術。 |
| 來自現代待命模式的 WoV | 透過語音喚醒從新式待命（S0ix）螢幕關閉狀態到螢幕亮起全電源（S0）狀態。 |
| 現代待機模式 | Windows 低電源閒置架構 - 繼承 Windows 10 中聯機待命（CS）的後繼技術。 新式待命的第一個狀態是螢幕關閉時。 最深的睡眠狀態是在 DRIPS/Resiliency 中。 如需詳細資訊，請參閱 新式待命。 |
| KWS | 關鍵字偵測器 – 提供「Hey Contoso」偵測的演算法。 |
| SW KWS | 軟體關鍵詞偵測器 – 在主機上執行的關鍵詞偵測系統實作（CPU）。 對於 「Hey Cortana」，SW KWS 會包含在 Windows 中。 |
| 硬體 KWS | 硬體關鍵字偵測器 – 在硬體上卸載執行的 KWS 實作。 |
| 突發緩衝區 | 循環緩衝區用於儲存 PCM 資料，在觸發 KWS 偵測時可能會迅速釋放，以確保所有觸發 KWS 偵測的音訊都被包含在內。 |
| 事件偵測器 OEM 配接器 | 使用者模式元件，可作為 Windows 語音助理堆疊與驅動程式之間的中介。 |
| 型號 | KWS 演算法所使用的原音模型數據檔。 數據檔是靜態的。 模型會針對每個地區進行在地化。 |
| MVA | 多語音代理 - HWKWS DDI支援多個代理。 |
| SVA | 單一語音代理程式 - 先前的 HWKWS DDI，僅支援單一代理程式 （Cortana） 。 |
整合硬體關鍵詞檢測器
若要實作硬體關鍵詞監測器（HW KWS），SoC 廠商必須完成下列工作。
- 根據本主題稍後所述的SYSVAD範例建立自定義關鍵詞偵測器。 您將在 COM DLL 中實作這些方法，如 IEvent 偵測器 OEM 配接器介面中所述。
- 實作 WAVE RT 增強功能，如 WAVERT 增強功能中所述。
- 提供 INF 檔案項目，以描述用於關鍵詞偵測的任何自定義 APO。
- 請檢閱 音訊裝置建議中的硬體建議和測試指引。 本主題提供設計和開發要與 Microsoft 語音平台搭配使用的音訊輸入裝置的指引和建議。
- 支援分段和串聯的命令。
- 符合語音助理的地區設定需求
- APOs （音訊處理物件） 必須提供下列效果：
- AEC
- AGC
- NS
- MFX APO 必須報告語音處理模式的效果。
- APO 可能會以 MFX 的形式執行格式轉換。
- APO 必須輸出下列格式：
- 16 kHz、mono、FLOAT。
- 選擇性地設計任何自定義 API，以增強音訊擷取程式。 如需詳細資訊，請參閱 Windows 音訊處理物件。
硬體卸載關鍵詞辨識器（HW KWS）WoV 需求
- HW KWS WoV 在 S0 工作狀態和 S0 睡眠狀態（又稱新式待命）期間受到支援。
- S3 不支援 HW KWS WoV。
AEC
AEC可以在捕獲突發音訊時由DSP執行，也可以稍後透過軟體APO完成。 為了以軟體 AEC 處理 KWS 突發數據，必須擁有從突發數據被擷取時相應的環回音訊。 為此，為突發輸出創建了自定義音頻格式，該格式將環回音頻交錯到突發音頻數據中。
從 Windows 20H1 版開始，Microsoft AEC APO 會知道此交錯格式，並可以使用它來執行 AEC。 如需詳細資訊，請參閱 KSPROPERTY_INTERLEAVEDAUDIO_FORMATINFORMATION。
驗證
使用 Voice Activation Manager 2 測試驗證 KSPROPSETID_SoundDetector2 屬性的硬體支援。
範例程式代碼概觀
音訊驅動程式有範例程序代碼，會在 GitHub 上實作語音啟用，做為 SYSVAD 虛擬音訊配接器範例的一部分。 建議使用此 程式碼 作為起點。
如需 SYSVAD 範例音訊驅動程式的詳細資訊，請參閱 範例音訊驅動程式。
關鍵詞辨識系統資訊
語音啟用音訊堆疊支援
啟用語音激活的音訊堆疊的外部介面可作為語音平台和音訊驅動程式的通訊管線。 外部介面分成三個部分。
- 事件偵測器裝置驅動程式介面 （DDI）。 事件偵測器裝置驅動程式介面負責設定和啟用硬體關鍵字偵測器（KWS）。 驅動程式也會使用它來通知系統偵測事件。
- IEvent 偵測器 OEM 配接器 DLL。 此 DLL 會實作 COM 介面，以調整驅動程式特定的不透明數據，以供 OS 用來協助進行關鍵詞偵測。
- WaveRT 增強功能。 提升功能可讓音訊驅動程序爆發地串流來自關鍵詞偵測的緩衝音訊數據。
音訊端點屬性
音訊端點圖形建置通常會發生。 圖表已準備好處理速度比即時擷取快。 所擷取緩衝區上的時間戳保持不變。 具體而言，時間戳記將正確反映過去擷取並緩衝的資料，而現在正在突發。
藍牙略過音訊串流理論
驅動程式會像往常一樣公開其擷取裝置的 KS 篩選器。 此篩選支持數個 KS 屬性和 KS 事件，以設定、啟用和發出偵測事件的訊號。 過濾器還包括一個額外的針腳工廠，識別為關鍵詞Spotter(KWS)針腳。 此接頭用於從關鍵詞檢測器串流音訊。
該屬性為：KSPROPSETID_SoundDetector2
所有 KSPROPSETID_SoundDetector2 屬性都會使用 KSSOUNDDETECTORPROPERTY 資料結構來呼叫。 此數據結構包含 KSPROPERTY，以及要武裝、重設、偵測到等關鍵詞的事件識別碼。
- 支援的關鍵字型態 - KSPROPERTY_SOUNDDETECTOR_PATTERNS。 這個屬性是由作系統所設定，以設定要偵測到的關鍵詞。
- 關鍵字模式 GUID 清單 - KSPROPERTY_SOUNDDETECTOR_SUPPORTEDPATTERNS。 這個屬性可用來取得識別支援模式類型的 GUID 清單。
- 啟用 - KSPROPERTY_SOUNDDETECTOR_ARMED。 這個讀寫屬性是簡單的布爾值狀態，指出偵測器是否已啟動。 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)
作業順序
系統啟動
- OS 會傳送 KSPROPERTY_SOUNDDETECTOR_RESET 來清除任何先前的偵測器狀態，將所有偵測器重設為撤防，並清除先前設定的模式。
- OS 會查詢 KSPROPERTY_SOUNDDETECTOR_PATTERNS 以擷取事件偵測器 OEM 配接器的 clsid。
- OS 會使用事件偵測器 oem 配接器來擷取支援的關鍵字和語言清單。
- OS 會註冊驅動程式所傳送的自定義 PNP 通知
- OS 會設定必要的關鍵字模式。
- 作業系統會啟動偵測器
內部驅動程式和硬體作業
當偵測器處於啟用狀態時，硬體可以在小型 FIFO 緩衝區中持續擷取和緩衝音訊資料。 （此 FIFO 緩衝區的大小取決於本檔外部的需求，但通常為數百毫秒到數秒。偵測算法會在透過這個緩衝區串流的數據上運作。 驅動程式和硬體的設計是，在啟動時，驅動程式和硬體之間不會有互動，而且在偵測到關鍵字之前，不會發送中斷信號到「應用程式」處理器。 這可讓系統在沒有其他活動的情況下達到較低的電源狀態。
當硬體偵測到關鍵詞時，會產生中斷。 在等待驅動程式處理中斷期間，硬體會繼續將音訊捕捉到緩衝區中，確保在關鍵詞之後不會遺失任何資料，並在緩衝限制內保持完整。
關鍵詞時間戳記
偵測到關鍵字後，所有語音啟動解決方案都必須緩衝所有口語關鍵字，包括關鍵字開始前的 1.6 秒。 音訊驅動程式必須提供時間戳，以識別數據流中關鍵片語的開始和結尾。
為了支持關鍵詞開始/結束的時間戳，DSP 軟體可能需要在內部根據 DSP 時鐘打上事件的時間戳。 偵測到關鍵詞之後，DSP 軟體會與驅動程式互動以準備 KS 事件。 驅動程式和 DSP 軟體必須將 DSP 時間戳對應至 Windows 性能計數器值。 執行這項作的方法專屬於硬體設計。 其中一個可能的解決方案是讓驅動程式讀取目前的性能計數器、查詢目前的 DSP 時間戳、再次讀取目前的性能計數器，然後估計性能計數器與 DSP 時間之間的相互關聯。 然後，假設相互關聯，驅動程式可以將關鍵詞 DSP 時間戳對應至 Windows 性能計數器時間戳。
IEvent Detector OEM 適配器介面
OEM 提供 COM 物件實作，做為 OS 與驅動程式之間的媒介，協助計算或剖析透過 KSPROPERTY_SOUNDDETECTOR_PATTERNS 和 KSPROPERTY_SOUNDDETECTOR_MATCHRESULT寫入和讀取音訊驅動程式的不透明數據。
COM物件的 CLSID 是 KSPROPERTY_SOUNDDETECTOR_SUPPORTEDPATTERNS所傳回的偵測器模式類型 GUID。 OS 會呼叫 CoCreateInstance，傳遞模式類型 GUID，以具現化與關鍵字模式類型相容的適當 COM 物件，並呼叫物件 IEventDetectorOemAdapter 介面上的方法。
COM 線程模型需求
OEM 的實作可能會選擇任何 COM 執行緒模型。
IEventDetectorOemAdapter
介面設計會嘗試讓物件實作保持無狀態。 換句話說，實作應該不需要在方法呼叫之間儲存任何狀態。 事實上，內部 C++ 類別可能不需要任何成員變數，除了那些實作 COM 物件所需的。
方法
實作下列方法。
- IEventDetectorOemAdapter：：BuildArmingPatternData
- IEventDetectorOemAdapter：：ComputeAndAddUserModelData
- IEventDetectorOemAdapter：：GetCapabilities
- IEventDetectorOemAdapter：：GetCapabilitiesForLanguage
- IEventDetectorOemAdapter::ParseDetectionResultData
- IEventDetectorOemAdapter：：ReportOSDetectionResult
- IEventDetectorOemAdapter：：VerifyUserEventData
WAVERT 功能強化
Miniport 介面被定義為由 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：：SetWritePacket、IMiniportWaveRTOutputStream：：GetOutputStreamPresentationPosition 和 IMiniportWaveRTOutputStream：：GetPacketCount。
效能計數器時間戳
數個驅動程式例程會傳回 Windows 性能計數器時間戳，以反映裝置擷取或呈現樣本的時間。
在具有複雜 DSP 管線和訊號處理的裝置中，計算精確的時間戳可能具有挑戰性，而且應該深思熟慮地完成。 時間戳不應只反映樣本傳送到OS或從OS傳送到 DSP 的時間。
- 在 DSP 中，使用 DSP 的內部時鐘來追蹤樣本時間戳。
- 在驅動程式與 DSP 之間，計算 Windows 性能計數器與 DSP 時鐘之間的相互關聯。 程式的範圍可以從非常簡單（但不太精確）到相當複雜或新穎（但更精確）。
- 請將因訊號處理演算法、管線或硬體傳輸所造成的任何持續延遲列入考量，除非這些延遲已被考慮在內。
突發讀取操作
本節說明突發讀取的OS與驅動程序互動。 只要驅動程式支援基於封包的串流 WaveRT 模型，包括 IMiniportWaveRTInputStream::GetReadPacket 函式，即使在非語音啟用情境下也能發生突發讀取。
討論兩個爆發範例讀取情境。 在一個情境中，如果迷你埠支援針腳類別 KSNODETYPE_AUDIO_KEYWORDDETECTOR，則驅動程式會在偵測到關鍵字時開始擷取並內部緩衝數據。 在另一種情況下，如果OS無法迅速讀取數據，驅動程式可以選擇性地在WaveRT緩衝區之外內部緩衝數據，藉由呼叫IMiniportWaveRTInputStream::GetReadPacket。
若要釋放在切換到 KSSTATE_RUN 前擷取的數據，驅動程式必須保留精確的樣本時間戳記資訊以及緩衝的擷取數據。 時間戳會識別擷取樣本的取樣瞬間。
數據流轉換成KSSTATE_RUN之後，驅動程式會立即設定緩衝區通知事件，因為它已經有可用的數據。
在此事件中，OS 會呼叫 GetReadPacket（） 以取得可用數據的相關信息。
一。 驅動程式會傳回有效擷取數據的封包號碼（從 KSSTATE_STOP 轉換到KSSTATE_RUN之後的第一個封包 0），OS 可以從中衍生 WaveRT 緩衝區內的封包位置，以及相對於數據流開頭的封包位置。
b。 驅動程式也會傳回性能計數器值，這個值會對應至封包中第一個樣本的取樣瞬間。 請注意，此性能計數器值可能相對較舊，這取決於在硬體或驅動程式中（而非 WaveRT 緩衝區）已緩衝了多少擷取數據。
丙. 如果有更多未讀取的緩衝數據可供驅動程式使用：i。 立即將該數據傳輸到 WaveRT 緩衝區的可用空間（也就是從 GetReadPacket 傳回之封包未使用的空間）、針對 MoreData 傳回 true，並在從這個例程傳回之前設定緩衝區通知事件。 或者，ii. 程序硬體將下一個封包高載到 WaveRT 緩衝區的可用空間、針對 MoreData 傳回 false，稍後會在傳輸完成時設定緩衝區事件。
OS 會使用 GetReadPacket（） 傳回的資訊，從 WaveRT 緩衝區讀取數據。
OS 會等候下一個緩衝區通知事件。 如果驅動程式在步驟 （2c） 中設定緩衝區通知，等候可能會立即終止。
如果驅動程式未在步驟 （2c） 中立即設定事件，則驅動程式會在將更多擷取的數據傳輸至 WaveRT 緩衝區之後設定事件，並使 OS 可供讀取
移至 （2）。
針對 KSNODETYPE_AUDIO_KEYWORDDETECTOR 關鍵詞偵測器針腳，驅動程序應該為至少 5000 毫秒的音訊數據配置足夠的內部高載緩衝。 如果 OS 無法在緩衝區溢位之前於針腳上建立數據流，則驅動程式可能會結束內部緩衝活動並釋放相關聯的資源。
語音喚醒
語音喚醒 （WoV） 可讓使用者透過說出特定關鍵字，例如「Hey Contoso」，將語音辨識引擎從低電源狀態啟動並查詢為螢幕開啟的全電源狀態。
此功能允許設備在設備空閒且屏幕關閉時始終監聽用戶的聲音。 這是由於聆聽模式與普通麥克風錄音相比，它使用的電量要少得多。 WoV 允許使用鏈結語音片語，例如「嘿 Contoso，我的下一個約會是什麼時候」，以免持方式引發語音助理的回應。
音訊堆疊負責傳達喚醒資料（說話者ID、關鍵字觸發器、置信度上的上下文資訊），以及通知感興趣的客戶已偵測到關鍵字。
新式待命系統的驗證
來自系統閒置狀態的 WoV 可以在 現代待命 系統上進行驗證，使用 現代待命語音喚醒基本測試在 AC 電源 上，以及 現代待命語音喚醒基本測試在 DC 電源 上於 HLK中。 這些測試會檢查系統是否有硬體關鍵詞辨識器（HW-KWS），能夠進入深度運行閒置平台狀態（DRIPS），而且可以透過語音命令從現代待命模式喚醒，系統恢復延遲不超過一秒。
ACX 和 MVA
音訊類別延伸模組（ACX）定義了音訊領域的 Windows 驅動程式架構（WDF）類別擴充。 如需 ACX 的詳細資訊，請參閱 ACX 音訊類別延伸模組概觀 和 ACX 物件摘要。 本節說明如何使用 ACX 實作 MVA。
ACX 會針對關鍵字偵測器使用相同的 KS 基礎結構，新增抽象層以簡化驅動程式實作。 使用 ACX 時，會使用相同的 OEM DLL，如上所述，而且保持不變。 ACX 和 Portcls 都需要 IEventDetectorOEMAdapter 介面，而且兩者之間對於 OEM 配接器實作沒有差異。
AcxKeywordSpotterCreate 函式可用來建立 ACX 關鍵字偵測器不透明物件 （ACXKEYWORDSPOTTER） ，該物件將與線路裝置物件父項相關聯。
ACXKEYWORDSPOTTER 物件可用來取代所有KSPROPERTY_SOUNDDETECTOR呼叫，以簡化 KWS 實作。 它用於將KWS元件和KWS引腳添加到ACX電路的過程中。 關聯的回調負責獲取模式、佈防、撤防和重置。 它使用初始化的 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 自動將串流與串流橋接器建立關聯。