多重語音助理

  • 發行項

Multiple Voice Assistant 平臺支援 Windows 中的其他語音助理。 這可讓其他助理在 Windows 裝置上使用，例如電腦，以及 HoloLens 之類的穿戴式裝置。 您可以使用一組支援的關鍵字模式，在同一部裝置上啟用多個語音助理。

注意

從 Windows 10 1903 版開始，支援多個語音助理。

如需實作 Windows Cortana 的相關資訊，請參閱 語音啟用。

語音啟用

語音啟用是一項功能，可讓使用者說出特定片語，從各種裝置電源狀態叫用語音辨識引擎。

實作語音啟用是重要的專案，而且是由 SoC 廠商完成的工作。 OEM 可以連絡其 SoC 廠商，以取得其 SoC 實作語音啟用的相關資訊。

語音啟用可讓使用者在作用中內容之外快速參與語音助理體驗 (，也就是目前使用語音的螢幕) 。 使用者通常想要能夠立即存取體驗，而不需要實際與裝置互動或觸控。 針對 Xbox 使用者，這可能不是想要尋找並聯機控制器。 對於電腦使用者，他們可能想要快速存取體驗，而不需要執行多個滑鼠、觸控和/或鍵盤動作，就像在廚房的電腦一樣。

語音啟用是由關鍵字 spotter 所提供， (KWS) 會在偵測到關鍵字組時做出反應。 關鍵字組可能包含關鍵字，例如「Hey Contoso」。 關鍵字偵測 會描述硬體或軟體偵測關鍵字。

關鍵字組可以自行表達 (「Hey Contoso」) 為分段命令，或後面接著撰寫鏈結命令的語音動作， (「Hey Contoso，我下一個會議在哪裡？」)

Microsoft 提供 OS 預設關鍵字 spotter (軟體關鍵字 spotter) ，以在硬體關鍵字偵測無法使用的情況下提供語音助理體驗。 雖然這目前適用于 Cortana，但可能需要額外的 Microsoft 設定，才能讓其他語音助理上線以進行雙階段關鍵字偵測。 如需詳細資訊，請連絡 AskMVA@Microsoft.com 。

如果 KWS 是從低電源狀態喚醒裝置，解決方案稱為「語音喚醒」 (WoV) 。 如需詳細資訊，請參閱本文稍後 的喚醒語音 。

名詞解釋

此詞彙摘要說明與語音啟用相關的詞彙。

詞彙 範例/定義
分段命令 範例：Hey Contoso < 暫停，等候助理 UI > 天氣為何？ 這有時稱為「雙次命令」或「僅限關鍵字」。
鏈結命令 範例：Hey Contoso 天氣為何？ 這有時稱為「單次命令」。
語音啟用 範例：「Hey Contoso」 在預先定義的啟用關鍵字片語中偵測到關鍵字的案例。
WoV (喚醒) 啟用從螢幕關閉、降低電源狀態到全電源狀態螢幕的語音啟用技術。
來自新式待命的 WoV 從新式待命 (S0ix) 螢幕關閉狀態喚醒到全電源 (S0) 狀態的畫面。
新式待命 Windows 低電源閒置基礎結構 - Windows 10中連線待命 (CS) 的後續任務。 新式待命的第一個狀態是螢幕關閉時。 最深的睡眠狀態是在 DRIPS/Resiliency 中。 如需詳細資訊，請參閱 新式待命。
KWS 關鍵字 spotter – 提供 「Hey Contoso」 偵測的演算法。
SW KWS Software 關鍵字 spotter – 在主機上執行的 KWS 實作， (CPU) 。 針對 「Hey Cortana」，SW KWS 包含在 Windows 中。
HW KWS Hardware 關鍵字 spotter – 在硬體上執行卸載的 KWS 實作。
高載緩衝區 用來儲存在 KWS 偵測事件中高載 PCM 資料的迴圈緩衝區，因此會包含觸發 KWS 偵測的所有音訊。
事件偵測器 OEM 配接器 使用者模式元件，可作為 Windows 語音助理堆疊與驅動程式之間的媒介。
型號 KWS 演算法所使用的原音模型資料檔案。 資料檔案是靜態的。 模型已當地語系化，每個地區設定一個。
Mva 多重語音代理程式 - 支援多個代理程式的 HWKWS DDI。
SVA 單一語音代理程式 - 先前的 HWKWS DDI 僅支援單一代理程式 (Cortana) 。

整合 Hardware 關鍵字 Spotter

若要實作硬體關鍵字 spotter (HW KWS) SoC 廠商必須完成下列工作。

硬體卸載關鍵字 spotter (HW KWS) WoV 需求

  • S0 工作狀態和 S0 睡眠狀態也稱為新式待命期間，支援 HW KWS WoV。
  • S3 不支援 HW KWS WoV。

AEC

AEC 可以在擷取高載音訊時由 DSP 執行，也可以透過軟體 APO 稍後完成。 若要執行具有 KWS 高載資料的軟體 AEC，必須從擷取高載資料的時間取得對應的回送音訊。 若要這樣做，會建立高載輸出的自訂音訊格式，以將回送音訊交錯到高載音訊資料。

從 Windows 20H1 版開始，Microsoft AEC APO 知道此交錯格式，並可用來執行 AEC。 如需詳細資訊，請參閱 KSPROPERTY_INTERLEAVEDAUDIO_FORMATINFORMATION。

驗證

使用語音啟用管理員 2 測試驗證KSPROPSETID_SoundDetector2屬性的 HW 支援。

範例程式碼概觀

音訊驅動程式有範例程式碼，可在 GitHub 上實作語音啟用，作為 SYSVAD 虛擬音訊配接器範例的一部分。 建議使用此 程式碼 作為起點。

如需 SYSVAD 範例音訊驅動程式的詳細資訊，請參閱 範例音訊驅動程式。

關鍵字辨識系統資訊

語音啟用音訊堆疊支援

啟用語音啟用的音訊堆疊外部介面可作為語音平臺和音訊驅動程式的通訊管線。 外部介面分成三個部分。

音訊端點屬性

音訊端點圖形建置通常會發生。 圖表已準備好處理速度比即時擷取快。 所擷取緩衝區上的時間戳記維持為 true。 具體而言，時間戳記會正確地反映過去和緩衝中擷取的資料，而且現在會高載。

藍牙略過音訊串流的理論

驅動程式會像往常一樣公開其擷取裝置的 KS 篩選器。 此篩選支援數個 KS 屬性和 KS 事件，以設定、啟用和發出偵測事件的訊號。 此篩選也包含識別為關鍵字 spotter 的其他釘選處理站， (KWS) 針腳。 這個釘選可用來串流關鍵字 spotter 的音訊。

屬性為： KSPROPSETID_SoundDetector2

所有 KSPROPSETID_SoundDetector2 屬性都會使用 KSSOUNDDETECTORPROPERTY 資料結構呼叫。 此資料結構包含 KSPROPERTY，以及要啟動、重設、偵測到等關鍵字的事件識別碼。

  • 支援的關鍵字類型 - 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. 作業系統會註冊驅動程式所傳送的自訂 PNP 通知
  5. OS 會 () 設定必要的關鍵字模式。
  6. 作業系統會 (偵測器)

內部驅動程式和硬體作業

雖然偵測器已啟動，但硬體可以在小型 FIFO 緩衝區中持續擷取和緩衝音訊資料。 (此 FIFO 緩衝區的大小取決於本檔外部的需求，但通常為數百毫秒到數秒。) 偵測演算法會在此緩衝區串流處理資料。 驅動程式和硬體的設計，在偵測到關鍵字之前，驅動程式與硬體之間沒有互動，而且不會中斷「應用程式」處理器。 如果沒有任何其他活動，這可讓系統達到較低的電源狀態。

當硬體偵測到關鍵字時，會產生中斷。 等候驅動程式服務中斷時，硬體會在緩衝限制內繼續擷取音訊到緩衝區，確保關鍵字遺失之後不會有任何資料。

關鍵字時間戳記

偵測到關鍵字之後，所有語音啟用解決方案都必須緩衝所有口語關鍵字，包括 1.6s 之後，才開始關鍵字。 音訊驅動程式必須提供時間戳記，以識別資料流程中關鍵字組的開始和結尾。

為了支援關鍵字開始/結束時間戳記，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 物件所需的任何成員變數。

方法

實作下列方法。

WAVERT 增強功能

Miniport 介面是由 WaveRT 迷你埠驅動程式所定義。 這些介面提供方法來簡化音訊驅動程式、改善 OS 音訊管線效能和可靠性，或支援新的案例。 定義 PnP 裝置介面屬性，可讓驅動程式為其緩衝區大小條件約束提供靜態運算式給 OS。

緩衝區大小

在 OS、驅動程式和硬體之間移動音訊資料時，驅動程式會在各種限制下運作。 這些限制可能是因為在記憶體和硬體之間移動資料的實體硬體傳輸，以及/或因為硬體或相關聯的 DSP 內的訊號處理模組所致。

HW-KWS 解決方案必須支援至少 100 毫秒和最多 200 毫秒的音訊擷取大小。

驅動程式會在 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 未透過呼叫 IMiniportWaveRTInputStream：：GetReadPacket來快速讀取資料，則驅動程式可以選擇性地在內部緩衝處理資料。

若要在轉換至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 無法在緩衝區溢位之前于針腳上建立資料流程，則驅動程式可能會結束內部緩衝活動並釋放相關聯的資源。

喚醒語音

喚醒語音 (WoV) 可讓使用者透過說出特定關鍵字，從低電源狀態啟動和查詢語音辨識引擎到具有畫面的完整電源狀態，例如 「Hey Contoso」。

此功能可讓裝置在裝置閒置且螢幕關閉時一律接聽使用者的語音。 這是因為與一般麥克風錄製相比，使用較少的電源接聽模式。 WoV 允許鏈結的語音片語，例如「Hey Contoso， when's my next appointment」 來叫用語音助理的回應。

音訊堆疊負責將喚醒資料 (說話者識別碼、關鍵字觸發程式、信賴等級的內容資訊) ，以及通知感興趣的用戶端已偵測到關鍵字。

新式待命系統上的驗證

來自系統閒置狀態的 WoV 可以在新式待命系統上使用AC 電源上的新式待命喚醒基本測試，以及HLK中DC 電源來源上的新式待命喚醒基本測試來驗證。 這些測試會檢查系統是否有硬體關鍵字 spotter (HW-KWS) ，能夠進入最深的執行時間閒置平臺狀態 (DRIPS) ，而且能夠在語音命令上從新式待命喚醒，且系統繼續延遲小於或等於一秒。

ACX 和 MVA

音訊類別 eXtension (ACX) 定義音訊網域的 Windows Driver Framework (WDF) 類別延伸模組。 如需 ACX 的詳細資訊，請參閱 ACX 音訊類別延伸模組概觀 和 ACX 物件的摘要。 本節說明如何使用 ACX 實作 MVA。

ACX 會針對關鍵字 Spotter 使用相同的 KS 基礎結構，新增一層抽象概念，以簡化驅動程式實作。 使用 ACX 時，會使用如上所述的相同 OEM DLL，且保持不變。 ACX 和 Portcls 都需要 IEventDetectorOEMAdapter 介面，而且 OEM 介面卡兩者之間的實作沒有任何差異。

AcxKeywordSpotterCreate 函式是用來建立 ACX 關鍵字 spotter 不透明物件 (ACXKEYWORDSPOTTER) ，該物件會與線路裝置物件父系相關聯。

ACXKEYWORDSPOTTER 物件可用來取代所有KSPROPERTY_SOUNDDETECTOR呼叫，以簡化 KWS 實作。 它會用於將 KWS 元素和 KWS 針腳新增至 ACX 線路的程式。 相關聯的回呼會負責取得模式、Arming、解除防護和重設。 它會使用初始化 ACX_KEYWORDSPOTTER_CONFIG結構 來描述關鍵字 spotter 的組態。

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 範例程式碼會顯示回呼、關鍵字元素的初始化，以及關鍵字 Spotter 的建立。

{
    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 關鍵字 spotter 物件，並將它與現有的線路產生關聯。

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

然後判斷關鍵字 Spotter 內容，並用來在 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 實作的必要部分，但可提供開發實際關鍵字 Spotter 的良好起點。

最後，會設定並建立 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 自動將串流與串流網橋產生關聯。

另請參閱

語音啟用