共用方式為


語音啟用

備註

本文主要參考 Windows 10 (1909 版和更早版本) 中提供的取用者體驗。 如需詳細資訊,請參閱 終止對 Cortana 的支援

Cortana 是 Windows 語音平台,為 Windows 10 中的所有語音體驗提供支持,例如 Cortana 和聽寫。 語音啟動是一項功能,可讓使用者透過說出特定片語「嘿 Cortana」,從各種裝置電源狀態呼叫語音辨識引擎。若要建立支援語音啟用技術的硬體,請檢閱本文中的資訊。

備註

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

Cortana 終端用戶體驗

若要瞭解 Windows 中可用的語音互動體驗,請檢閱這些文章。

文章 說明
什麼是 Cortana? 提供 Cortana 的概觀和使用方向

“Hey Cortana” 語音啟用和「瞭解我的聲音」簡介

「Hey Cortana」語音啟用

「嘿 Cortana」語音激活(VA)功能允許使用者透過語音命令快速啟動 Cortana,以便在不受限於當前螢幕顯示內容的情況下體驗 Cortana。 使用者通常希望能夠立即存取體驗,而無需進行實體互動或觸摸裝置。 手機使用者可能正在車內駕駛,並將注意力和雙手集中在操作車輛上。 Xbox 使用者可能不想尋找並連接控制器。 電腦使用者可能想要快速存取體驗,而不需要執行多個滑鼠、觸控或鍵盤動作。 例如,在廚房裡做飯時使用電腦。

語音激活通過預定義的關鍵短語或激活短語提供始終聆聽的語音輸入。 關鍵片語可以自行說出 (“Hey Cortana”) 作為階段性命令,或後面接著語音指令,例如“嘿 Cortana,我的下一個會議在哪裡?”,一個連續命令。

關鍵字 偵測 一詞描述硬體或軟體偵測關鍵字。

只有當說出 Cortana 關鍵詞時才會發生 啟用,Cortana 將會啟動並播放 EarCon 音效,表示它已進入接聽模式。

鏈結命令描述在關鍵字之後立即發出命令的能力 (例如「嘿 Cortana,呼叫 John」),並讓 Cortana 啟動 (如果尚未啟動) 並遵循命令 (與 John 開始通話)。

此圖說明鏈式啟用和僅限關鍵詞的啟用。

圖表顯示串接啟用和僅限關鍵詞啟用與音訊緩衝區和時間序列之間的差異。

Microsoft 提供作業系統預設的關鍵字偵測器(軟體關鍵字偵測器),用來確保硬體關鍵字偵測的品質,並在硬體關鍵字偵測缺失或無法使用時提供 Hey Cortana 體驗。

「瞭解我的聲音」功能

「瞭解我的聲音」功能可讓用戶訓練 Cortana 辨識其獨特的語音。 這可以通過用戶在 Cortana 設定畫面中選取「瞭解如何說『嘿 Cortana』」來完成。 然後,使用者重複六個精心挑選的短語,這些短語提供了足夠多樣的語音模式來識別使用者聲音的獨特屬性。

Cortana 桌面設定的螢幕快照,顯示硬體關鍵字偵測器和語音喚醒功能。

當語音啟動與「學習我的聲音」配對時,這兩種演算法會協同工作以減少錯誤啟動。 對於會議室案例來說,這特別有價值,其中一個人在充滿裝置的房間里說“Hey Cortana”。 此功能僅適用於 Windows 10 版本 1903 和更早版本。

語音啟用是由關鍵詞 Spotter (KWS) 提供,當偵測到關鍵片語時會做出反應。 如果 KWS 是從低電源狀態喚醒裝置,則解決方案稱為「語音喚醒」(WoV)。 如需詳細資訊,請參閱 語音喚醒

術語詞彙表

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

術語 範例/定義
階段性命令 範例:嘿 Cortana <暫停,等待 EarCon 聲音> 現在的天氣如何? 這有時稱為「雙發指令」或「僅關鍵字」
鏈結命令 範例:嘿 Cortana 天氣怎麼樣? 這有時稱為「一次性命令」
語音啟用 提供預先定義啟動關鍵詞組之關鍵字偵測的情境。 例如,“Hey Cortana” 是Microsoft語音啟用案例。
WoV 語音喚醒技術 – 此技術可在螢幕關閉的低功耗狀態下,通過語音激活使螢幕進入全功耗狀態。
來自現代待命模式的 WoV 透過語音喚醒從新式待命(S0ix)螢幕關閉狀態到螢幕亮起全電源(S0)狀態。
現代待機模式 Windows 低電源閒置架構 - 繼承 Windows 10 中聯機待命(CS)的後繼技術。 新式待命的第一個狀態是螢幕關閉時。 最深的睡眠狀態是在 DRIPS/Resiliency 中。 如需詳細資訊,請參閱 現代待命
KWS 關鍵字偵測器 – 用於偵測「嘿小娜」的演算法
SW KWS 軟體關鍵詞偵測器 – 在主機上執行的關鍵詞偵測系統實作(CPU)。 對於「嘿小娜」功能,SW KWS 作為 Windows 的一部分被包含在內。
硬體關鍵詞識別 (KWS) 硬體加速的關鍵詞檢測器 – 這是一種在硬體上執行的 KWS 實作。
突發緩衝器 一個循環緩衝區,用於存儲可以在 KWS 檢測中“突發”的 PCM 數據,以便包括觸發 KWS 檢測的所有音頻。
關鍵詞偵測器 OEM 配接器 驅動程式層級的夾層,可使啟用了 WoV 的硬體 (HW) 能夠與 Windows 和 Cortana 堆棧進行通訊。
型號 KWS 演算法所使用的原音模型數據檔。 數據檔是靜態的。 模型會針對每個地區進行在地化。

整合硬體關鍵詞檢測器

若要實作硬體關鍵字偵測器 (HW KWS) ,請完成下列工作。

硬體卸載關鍵詞辨識器(HW KWS)WoV 需求

  • HW KWS WoV 在 S0 工作狀態和 S0 睡眠狀態(又稱新式待命)期間受到支援。
  • S3 不支援硬體 KWS WoV。

HW KWS 的 AEC 需求

  • 針對 Windows 版本 1709

    • 若要支援 S0 睡眠狀態的硬體 KWS WoV (新式待命) ,不需要 AEC。
    • Windows 1709 版不支援適用於 S0 工作狀態的硬體 KWS WoV。
  • Windows 1803 版

    • HW KWS WoV 支援 S0 工作狀態。
    • 若要啟用 S0 工作狀態的 HW KWS WoV,APO 必須支援 AEC。

範例程式代碼概觀

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

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

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

關鍵詞辨識系統資訊

語音啟用音訊堆疊支援

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

  • 關鍵字偵測器裝置驅動程式介面(DDI)。 關鍵詞偵測器設備驅動器介面負責設定及啟用 HW 關鍵詞檢測器(KWS)。 驅動程式也會使用它來通知系統偵測事件。
  • 關鍵字偵測器 OEM 適配器 DLL。 此 DLL 會實作 COM 介面,以調整驅動程式特定的不透明數據,以供 OS 用來協助進行關鍵詞偵測。
  • WaveRT 串流增強功能。 提升功能可讓音訊驅動程序爆發地串流來自關鍵詞偵測的緩衝音訊數據。

音訊端點屬性

音訊端點圖形建置通常會發生。 圖表已準備好處理速度比即時擷取快。 所擷取緩衝區上的時間戳保持不變。 具體而言,時間戳能正確反映過去擷取並緩衝的資料,現在正在突發傳輸。

藍牙略過音訊串流理論

驅動程式會像往常一樣公開其擷取裝置的 KS 篩選器。 此篩選器支援數個 KS 屬性和 KS 事件,以設定、啟用及發出偵測事件訊號。 此篩選器還包含另一個被辨識為關鍵字偵測器(KWS)引腳的引腳工廠。 此接頭用於從關鍵詞檢測器串流音訊。

屬性為:

  • 支援的關鍵字型態 - KSPROPERTY_SOUNDDETECTOR_PATTERNS。 作業系統會設定此屬性,以配置要偵測的關鍵字。
  • 關鍵字模式 GUID 清單 - KSPROPERTY_SOUNDDETECTOR_SUPPORTEDPATTERNS。 這個屬性可用來取得識別支援模式類型的 GUID 清單。
  • 啟用 - KSPROPERTY_SOUNDDETECTOR_ARMED。 此讀取/寫入屬性是布林值狀態,指出偵測器是否已布防。 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 效能計數器值。 執行這項作的方法專屬於硬體設計。 其中一個可能的解決方案是讓驅動程式讀取目前的性能計數器、查詢目前的 DSP 時間戳、再次讀取目前的性能計數器,然後估計性能計數器與 DSP 時間之間的相互關聯。 然後,假設相互關聯,驅動程式可以將關鍵詞 DSP 時間戳對應至 Windows 性能計數器時間戳。

關鍵詞偵測器 OEM 配接介面

OEM 提供 COM 物件實作,做為 OS 與驅動程式之間的媒介,協助計算或剖析透過 KSPROPERTY_SOUNDDETECTOR_PATTERNSKSPROPERTY_SOUNDDETECTOR_MATCHRESULT寫入和讀取音訊驅動程式的不透明數據。

COM物件的 CLSID 是 KSPROPERTY_SOUNDDETECTOR_SUPPORTEDPATTERNS所傳回的偵測器模式類型 GUID。 OS 會呼叫 CoCreateInstance,傳遞模式類型 GUID,以具現化與關鍵字模式類型相容的適當 COM 物件,並呼叫物件的 IKeywordDetectorOemAdapter 介面上的方法。

COM 線程模型需求

OEM 的實作可能會選擇任何 COM 執行緒模型。

IKeywordDetectorOemAdapter

介面設計會嘗試讓物件實作保持無狀態。 換句話說,實作應該不需要在方法呼叫之間儲存任何狀態。 事實上,內部 C++ 類別可能不需要除了實作 COM 物件所需以外的任何成員變數。

方法

實作下列方法。

關鍵字ID

KEYWORDID 列舉會識別關鍵詞的片語文字/函式,而且也會用於Windows生物特徵辨識服務配接器。 如需詳細資訊,請參閱 生物特徵辨識架構概觀 - 核心平臺元件

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

關鍵字選擇器

KEYWORDSELECTOR 結構是一組唯一選取特定關鍵詞和語言的標識符。

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

處理模型數據

靜態用戶獨立模型 - OEM DLL 通常會包含一些內建於 DLL 中的靜態用戶獨立模型數據,或包含在 DLL 隨附的個別數據檔中。 GetCapabilities 例程所傳回的一組支援的關鍵詞標識碼將取決於此數據。 例如,如果 GetCapabilities 傳回的支援關鍵碼識別碼清單包含 KwHeyCortana,則靜態使用者無關模型數據會包含所有支援語言的「Hey Cortana」 (或其翻譯) 資料。

動態使用者相依模型 - IStream 提供隨機存取記憶體模型。 OS 會將 IStream 介面指標傳遞給 IKeywordDetectorOemAdapter 介面上的許多方法。 OS 會使用適當的存儲來支援 IStream 實作,並能儲存最多 1 MB 的資料。

OEM 會定義此記憶體內數據的內容和結構。 其目的是要持續儲存由 OEM DLL 計算或擷取的使用者相依模型數據。

操作系統可能會使用空的 IStream 呼叫介面方法,特別是在用戶從未訓練關鍵詞的情況下。 OS 會為每個使用者建立個別的 IStream 記憶體。 換句話說,指定的 IStream 會儲存唯一一個使用者的模型資料。

OEM DLL 開發人員決定如何管理使用者獨立和使用者相依數據。 不過,它絕不會儲存 IStream 外部的任何位置的用戶數據。 根據目前方法的參數,一個可能的 OEM DLL 設計會在內部切換存取 IStream 和靜態使用者獨立數據。 替代設計可能會在每次方法呼叫開始時檢查 IStream,若靜態的使用者獨立數據尚未存在,則將其新增至 IStream,以便方法的其餘部分僅需存取 IStream 來獲取所有模型數據。

訓練和運行音訊處理

如先前所述,訓練UI流程會在音訊串流中提供音素豐富的完整句子。 每個句子都會個別傳遞至 IKeywordDetectorOemAdapter::VerifyUserKeyword,以確認其包含預期的關鍵詞且具有可接受的品質。 UI 收集並驗證所有句子之後,它們都會在對 IKeywordDetectorOemAdapter::ComputeAndAddUserModelData 的一次呼叫中傳遞。

音訊會以獨特的方式處理語音激活訓練。 下表摘要說明語音啟用訓練與一般語音辨識使用方式之間的差異。

語音訓練 語音辨識
模式 未加工 原始或語音
正常 KWS
音訊格式 32 位元浮點數(類型 = 音頻,子類型 = IEEE_FLOAT,取樣率 = 16 kHz,位元 = 32) 由操作系統音效堆疊管理
麥克風 麥克風 0 陣列中的所有麥克風或單聲道

關鍵詞辨識系統概觀

此圖表提供關鍵詞辨識系統的概觀。

關鍵詞辨識系統的圖表,包括 Cortana、語音執行時和語音啟用管理員元件。

關鍵詞辨識順序圖表

在這些圖表中,語音執行階段模組顯示為語音平台。 如先前所述,Windows 語音平臺可用來支援 Windows 10 中的所有語音體驗,例如 Cortana 和聽寫。

在啟動期間,會使用 IKeywordDetectorOemAdapter::GetCapabilities匯集能力。

啟動期間關鍵詞辨識的順序圖表,其中顯示定型UX、語音平臺和 OEM 關鍵詞偵測器。

稍後當用戶選取 「瞭解我的聲音」時,會叫用訓練流程。

「學習我的聲音」過程中的關鍵字識別序列圖,顯示訓練 UX、語音平台和 OEM 關鍵字偵測器。

此圖表描述用於關鍵詞偵測的準備過程。

關鍵詞偵測期間關鍵詞辨識的順序圖表,其中顯示語音平臺、OEM 關鍵詞偵測器和音訊驅動偵測器。

WAVERT 功能強化

Miniport 介面被定義為由 WaveRT 小型端口驅動程式來實作。 這些介面提供方法來簡化音訊驅動程式、改善OS音訊管線效能和可靠性,或支援新的案例。 已定義新的 PnP 裝置介面屬性,讓驅動程式提供其緩衝區大小條件約束的靜態表達式給 OS。

緩衝區大小

驅動程式在將音訊資料從作業系統(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::SetWritePacketIMiniportWaveRTOutputStream::GetOutputStreamPresentationPositionIMiniportWaveRTOutputStream::GetPacketCount

效能計數器時間戳

數個驅動程式例程會傳回 Windows 性能計數器時間戳,以反映裝置擷取或呈現樣本的時間。

在具有複雜 DSP 管道和訊號處理的裝置中,計算準確的時間戳可能具有挑戰性,應深思熟慮。 時間戳記不應反映範例從作業系統傳輸至 DSP 的時間。

  • 在 DSP 中,使用 DSP 的內部時鐘來追蹤樣本時間戳。
  • 在驅動程式與 DSP 之間,計算 Windows 性能計數器與 DSP 時鐘之間的相互關聯。 此過程的範圍可以從簡單(但不太精確)到相當複雜或新穎(但更精確)。
  • 請將因訊號處理演算法、管線或硬體傳輸所造成的任何持續延遲列入考量,除非這些延遲已被考慮在內。

突發讀取操作

本節說明突發讀取的OS與驅動程序互動。 只要驅動程式支援基於封包的串流 WaveRT 模型,包括 IMiniportWaveRTInputStream::GetReadPacket 函式,即使在非語音啟用情境下也能發生突發讀取。

討論兩個爆發範例讀取情境。 在某個情境中,如果迷你埠支援具有特定針腳類別 KSNODETYPE_AUDIO_KEYWORDDETECTOR 的針腳,此驅動程式會在偵測到關鍵字時開始擷取並在內部暫存資料。 在另一種案例中,如果 OS 呼叫 IMiniportWaveRTInputStream::GetReadPacket,如果 OS 讀取數據的速度不夠快,驅動程式可以在 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 毫秒的音訊數據配置足夠的內部高載緩衝。 如果作業系統在緩衝區溢位之前無法在針腳上建立串流,則驅動程式可以結束內部緩衝活動並釋放相關資源。

語音喚醒

語音喚醒 (WoV) 可讓使用者透過說出特定關鍵字 (例如「Hey Cortana」) 來啟動和查詢語音辨識引擎,從螢幕關閉、低電源狀態到螢幕開啟、全電源狀態。

此功能可讓裝置在裝置處於低電源狀態時一律接聽使用者的語音,包括螢幕關閉且裝置閒置時。 它通過使用聆聽模式來實現這一點,與正常麥克風錄音期間的較高功耗相比,該模式的功耗較低。 低功耗語音識別允許用戶說出預定義的關鍵短語,例如“嘿 Cortana”,然後說出“我的下一次約會是什麼時候”等鏈結語音短語,以免提方式調用語音。 無論設備是在使用中還是在螢幕關閉的情況下空閒,這都有效。

音訊堆疊負責傳達喚醒資料 (說話者 ID、關鍵字觸發器、信賴等級) ,並通知感興趣的用戶端偵測到關鍵字。

新式待命系統的驗證

來自系統閒置狀態的 WoV 可以在 現代待命 系統上進行驗證,使用 現代待命語音喚醒基本測試在 AC 電源 上,以及 現代待命語音喚醒基本測試在 DC 電源 上於 HLK中。 這些測試會檢查系統是否有硬體關鍵詞辨識器(HW-KWS),能夠進入深度運行閒置平台狀態(DRIPS),而且可以透過語音命令從現代待命模式喚醒,系統恢復延遲不超過一秒。