Windows 系統中 WASAPI 延遲設定：完整指南

如果你在 Windows 系統中處理音頻，遲早會遇到以下問題： WASAPI延遲及其永恆的比較 ASIO 和 WASAPI任何使用 DAW 錄音、直播、玩線上遊戲或製作音樂的人都知道，幾毫秒的延遲就可能毀掉一次錄音，使聲音不同步，或讓遊戲變成一場折磨。

在 Windows 10 及更高版本中，微軟對其音訊堆疊進行了重大改進，如今可以實現 低得多的延遲 使用 WASAPI 的共享或獨佔模式無需犧牲瀏覽器音訊或其他應用程式的流暢度。關鍵在於理解技術堆疊的工作原理、哪些方面發生了變化、我們面臨的硬體限制，以及我們可以（作為使用者或開發者）調整哪些參數來榨取這額外的毫秒級效能。

什麼是音訊延遲？為什麼它如此重要？

當我們談到音訊延遲時，我們指的是… 從聲音產生到你聽到它或你的應用程式接收到它所經過的時間。這段時間以毫秒為單位來衡量，雖然從理論上似乎微不足道，但實際上決定了使用者體驗是流暢還是完全不舒適。

En 音樂作品 錄音方面，樂器演奏家需要 演奏時幾乎立即就能聽到如果每個音符需要幾十毫秒才能透過耳機傳回來，大腦就會開始難以分辨聽到的聲音和感覺到的聲音，保持節奏就會變成一種折磨。

En 流在播客和視訊通話中，延遲會導致 視訊和音訊不符、惱人的迴聲，以及「對著牆壁說話」的感覺耳機中自己的聲音延遲幾毫秒，會使揚聲器承受壓力，導致說話斷斷續續，聽起來也不自然。

對於遊戲玩家，尤其是那些喜歡射擊遊戲、競技遊戲或VR體驗的玩家來說， 音訊響應緩慢意味著錯過關鍵的聲音提示 （腳步聲、槍聲、警報聲）或註意到控制器操作和聲音不同步，這會破壞沉浸感；對於這些情況，學習如何…很有幫助。 測量電玩遊戲中的延遲 並採取相應行動。

更專業地說，通常會區分以下兩者： 播放延遲、錄製延遲、往返延遲和觸控相關延遲 （例如，觸摸螢幕並聽到聲音回饋）。所有這些加起來，了解它們有助於我們知道前進的方向。 El Temppo.

音訊路徑中的延遲類型

在 Windows 音訊堆疊中，使用了幾個概念來 描述聲音在傳播過程中每個階段的延遲。這不僅僅是一個學術問題：每種類型的延遲都有不同的原因和不同的緩解方法。

播放延遲是指 應用程式提供音訊緩衝進行播放到您透過揚聲器或耳機聽到聲音之間存在延遲。這包括緩衝區大小、格式轉換以及在此過程中應用的任何效果。

同時，捕獲延遲是 從麥克風捕獲的音訊到達應用程式所需的時間它涵蓋了從聲音進入換能器，經過介面、控制器和音訊引擎，直到軟體可以讀取該資料區塊的整個過程。

所謂的往返延遲是兩者的總和： 拍攝、在應用程式中處理，然後透過揚聲器播放在諸如 DAW 監聽之類的場景中，它真正發揮了作用，當你演奏時，訊號會透過電腦回到你的耳朵。

此外，在觸控介面中，人們經常會談到觸摸到應用程式的延遲和觸摸到聲音的延遲： 從您觸摸螢幕到事件被處理，再到系統發出聲音響應，這中間需要一段時間。對於虛擬樂器或 應用程序 對於使用 Windows 平板電腦或二合一電腦的創意工作者來說，這個流程應該盡可能短。

Windows音訊堆疊的組裝方式

在 WASAPI、ASIO 等協定之下，Windows 也擁有… 音訊堆疊包含一個中央引擎，用於混合音訊串流、應用效果、調整格式以及與控制器通訊。了解這條路徑有助於看出延遲的增加和減少在哪裡。

在播放過程中， 應用程式寫入音頻 資料儲存在 API 公開的緩衝區中。 Windows 音訊引擎讀取這些數據，對其進行處理（包括以 APO，即音訊處理物件的形式呈現的效果），處理完成後，將其轉儲到另一個緩衝區，驅動程式將使用該緩衝區將資料傳送至硬體。

這些APO相關的延遲 這取決於他們進行的處理（均衡、降噪、3D效果等）。演算法越複雜，需要累積的狀態越多，需要在緩衝區中儲存的樣本就越多，延遲就越大。

在 Windows 10 之前，只需透過音訊引擎即可。 播放浮點數資料耗時 12 毫秒，播放整數資料時耗時約 6 毫秒。自 Windows 10 以來，這部分功能已大幅優化，現在無論資料類型為何，回應時間都約為 1,3 毫秒。

處理完成後，引擎會將結果放入緩衝區，緩衝區的長度也會產生直接影響。 在先前的系統中，該緩衝區大小固定為大約 10 毫秒。在現代版本中，音訊驅動程式可以聲明不同的支援大小，並允許更小的值，例如 2-3 毫秒。

捕獲過程中也會發生類似的情況，但方向相反： 此硬體接收來自麥克風的訊號您可以應用效果（AGC、迴聲消除等），控制器會將這些資料轉儲到緩衝區中，音訊引擎會收集並使用自己的 APO 對其進行處理，然後再提供給應用程式。

在舊版本中，音訊引擎添加了一些捕獲功能。 浮點數資料處理時間為 6 毫秒，整數資料處理時間幾乎為 0 毫秒。自 Windows 10 以來，這部分的佔用空間已減少到幾乎可以忽略不計。即便如此，驅動程式和硬體端的緩衝區仍然會對總佔用空間產生影響。

還有一種獨佔音訊堆疊模式。如果一個應用程式以獨佔模式開啟一個端點， 它繞過混音引擎，直接與硬體緩衝區通訊。這進一步減少了延遲，但缺點是其他程式不能同時使用該輸入或輸出裝置。

ASIO、獨佔模式以及 WASAPI 改進如此之大的原因

多年來，實現這一目標的通常方法一直是 音樂製作中的低延遲意味著使用 ASIO 或獨佔模式的設備。使用 ASIO，DAW 幾乎可以直接與介面製造商的驅動程式通信，而無需系統混音器作為中間環節。

問題在於，這種方法也有其缺點： 通常需要特定的第三方司機該軟體必須能夠與該 API 通信，而且通常情況下，系統音訊（瀏覽器、遊戲、播放器）會被排除在外，或者你必須採用複雜的變通方法來路由它。

同時，WASAPI 的專屬模式也提供了類似的功能： 該應用程式的流程幾乎直接傳輸到設備。但是，此時其他應用程式將失去存取權限，而當你想要將 DAW 與 YouTube 影片、Discord 等混合使用時，這並不是最方便的事情。

為了避免在延遲和靈活性之間做出選擇，微軟 Windows 10 改進了共享堆疊，即使不進入獨佔模式也能降低延遲。引擎重量減輕了，最重要的是，增加了應用程式和驅動程式之間協商更小緩衝區大小的功能。

此外，還有一種特殊的資源管理模式：當應用程式開始使用非常短的緩衝區時， Windows 會優先處理與該音訊串流相關的執行緒。 並防止其他系統任務在關鍵時刻中斷處理。

DAW 和串流媒體用戶的 WASAPI 延遲設置

從最終使用者的角度來看，WASAPI 呈現為： 在許多數位音訊工作站（DAW）和錄音程式中，音訊設備選項之一例如，在 Reaper 中，經常可以看到 ASIO 和 WASAPI 延遲（包括獨佔模式和共享模式）之間的比較。

在某些情況下，從 ASIO 切換到獨佔 WASAPI 會導致 延遲甚至比使用製造商的 ASIO 驅動程式還要低。只要硬體和 Windows 驅動程式配置正確，這種情況雖然不常見，但確實會發生。一旦發生這種情況，用戶不想恢復到 ASIO 也是可以理解的。

但是，當切換到共用 WASAPI 時，它們可能會出現。 從數位音訊工作站 (DAW) 播放或錄製音訊時出現失真、喀嚓聲或雜音。雖然系統的其他聲音（瀏覽器、遊戲）播放沒有問題，但這通常是由於格式不匹配、緩衝過度或強制轉換造成的。

其中一種典型的衝突發生在系統強制設備以某種方式運作時。 位元深度格式與介面實際支援的格式不同。例如，WASAPI 在 DAW 對話方塊中顯示為 24 位，而在 Windows 聲音面板中，該音效卡在所有取樣率下僅提供 16 位。

在這些情況下，為了避免共用 WASAPI 出現失真，建議檢查 Windows 聲音選項。 位元深度和取樣率設定為預設值並確保 DAW 使用的格式與介面實際支援的格式相容。

在其他情況下，例如用麥克風錄製旁白 USB 在簡單的應用程式或像 Audacity 這樣的工具中，WASAPI 的使用最為廣泛。 用於擷取系統本身的音訊或 Windows 混音器的輸出。而不是為了實現盡可能低的延遲。

延遲、緩衝和人類感知

延遲通常以毫秒為單位進行測量，在實踐中通常認為： 延遲低於 10 毫秒左右，大多數人幾乎感覺不到。在 10 到 20 毫秒之間，對於一些要求較高的任務來說，延遲開始變得明顯，超過這個數值就會變得非常煩人。

當你戴著耳機聽自己說話時，任何 延遲時間超過 10 毫秒就會開始產生「內部迴聲」的感覺。如果延遲達到 30 或 40 毫秒，大多數人都會感到困惑，停止說話，或最終摘下耳機。

同時，數位音訊訊號可以用以下方式描述： 取樣頻率（單位：赫茲）和緩衝區大小（單位：取樣點）作為參考，44.100 Hz 表示波形每秒被分成 44.100 個樣本；48.000 Hz 表示每秒被分成 48.000 個樣本，依此類推。

緩衝區是一種小型資料儲存設備，音訊訊號會透過它進行傳輸。 越大，抵禦 CPU 尖峰負載或中斷的安全裕度就越高。但這樣做會增加幾毫秒的整體延遲。如果延遲降低過多，系統就需要更頻繁地喚醒來填滿剩餘空間，從而更容易崩潰或故障。

因此，在 DAW 或串流媒體應用程式中設定裝置時，通常會面臨選擇的問題。 緩衝區大小要夠小，以至於延遲不明顯。但不要過度使用，以免在實際工作過程中出現點擊或掉線的情況。

如何使用 WASAPI 降低 Windows 中的音訊延遲

為了改善 WASAPI 的使用體驗以及 Windows 系統中音訊的使用體驗，需要在硬體、軟體和系統層面採取或至少審查一些措施。

首先要確保 音訊硬體（介面、整合式音效卡、USB麥克風）及其驅動程式已正確安裝且為最新版本。Windows 10 中的許多低延遲改進都依賴 DDI 和僅存在於現代驅動程式中的屬性； 使用 LatencyMon 診斷延遲 檢測駕駛員問題是建議的做法。

在音樂領域，使用仍然是常態。 與高品質 ASIO 驅動程式配合使用，適用於 DAW、虛擬樂器或複雜混音。ASIO 仍然可以對緩衝區大小進行精細控制，如果 PC 專用於音頻，並且沒有受到超頻或並行運行繁重任務的壓力，則 ASIO 通常能夠保持穩定。

然而，在串流媒體和遊戲領域，ASIO 就變得不實用了，因為 大多數應用程式（遊戲、OBS、瀏覽器）都使用 Windows 原生驅動程式。 （DirectSound、WASAPI）。混合使用這些音源時，最好使用作業系統自帶的生態系。

有一條規則幾乎從未失效： 避免在訊號路徑中串聯不必要的設備和程式。每一次模數轉換、每一次經過效果處理器、每一次從一個應用程式跳到另一個應用程序，都會增加一些延遲和不匹配的風險。

例如，對著連接到專用介面並進行直接硬體混音的 XLR 麥克風說話，與以下情況並不相同： 需透過一條micro USB線、一個軟體變聲器、一個虛擬音訊路由器和一個USB遊戲耳機連接。在第二種情況下，步驟的總和必然會導致延遲飆升。

Windows 10 及更高版本中的延遲和特定改進

微軟不僅在 Windows 10 中優化了音訊引擎，還添加了一些機制… 應用程式和驅動程式協同工作，以減少往返延遲 在不完全犧牲共享堆疊靈活性的前提下。

首先，即使不更改程式碼，許多應用程式也已經發現 與 Windows 8.1 相比，往返延遲降低了 4,5 到 16 毫秒。這完全是由於引擎內部優化所致。使用浮點資料的用戶受益最大。

其次，如果系統有更新的驅動程序，這些驅動程式可以… 宣布使用比經典的 10 毫秒更小的緩衝區大小這樣一來，需要低延遲的應用就可以在播放和擷取過程中協商 5 毫秒、3 毫秒、1 毫秒等值。

此外，當應用程式開始使用非常小的緩衝區運行時， Windows 會啟動資源管理模式，該模式會優先考慮音訊子系統。：保護引擎、驅動程式和標記為關鍵音訊的應用程式的線程，以最大限度地減少中斷和故障。

這意味著，如果你開發一款需要快速回應的應用程序， 您可以信賴新的基礎設施 在硬體支援的情況下，可以在不犧牲共享模式的前提下實現非常低的延遲。

AudioGraph：用於創作和多媒體的現代化 API

AudioGraph 是專為通用 Windows 平台設計的 API。 具有更用戶友好抽象層的互動式音樂創作場景 它直接與 WASAPI 互動。它支援 C++、C#、JavaScript 和其他 .NET 語言。

為了實現低延遲，AudioGraph 公開了一個名為 的屬性 AudioGraphSettings::QuantumSizeSelectionMode這樣，您可以指定是使用系統的預設緩衝區大小、盡可能低的延遲，還是使用接近所需值的特定值。

它可以配置為使用預設緩衝區大小（約 10 毫秒），以便它選擇 音訊驅動程式支援的最低配置或者，嘗試在每個處理時間片內更接近應用程式所需的樣本數量。

官方範例展示如何僅用幾行程式碼建立音訊圖。 只需選擇最低延遲模式，即可實現最低延遲。此選項會在內部檢查設備支援哪些尺寸，並選擇在不超出允許限制的前提下最激進的尺寸。

AudioGraph 也處理 內部管理音訊執行緒並設定優先權因此，開發人員不必明確選擇 MMCSS 或直接使用即時佇列，即可受益於系統的低延遲模式。

WASAPI 和 IAudioClient3：對週期性的精細控制

供任何需要的人使用 它能提供比 AudioGraph 更底層的控制、更具體的功能，甚至更低的延遲。微軟透過新增介面 IAudioClient3 擴展了 WASAPI，該介面源自已知的 IAudioClient2。

此介面新增了以下方法： 檢查共享模式下音訊引擎的當前格式和頻率取得給定格式允許的周期範圍，並以特定週期開啟共用流，而不是接受預設值。

實際上，這使得應用程式能夠確定哪些緩衝區大小是合法的（最小值和最大值之間基本週期的倍數）， 選擇一個能夠平衡穩定性和延遲的特定值。 根據您的需要。

使用 IAudioClient3，您也可以指定流程使用 應用程式指定的格式，引擎中不進行重採樣前提是設備支援該格式。這樣可以避免中間轉換，從而減少複雜性和輕微延遲。

此外，微軟建議需要低延遲的 WASAPI 應用程式來建立其處理任務。 透過即時工作隊列（RT 工作隊列）或媒體基礎隊列將它們標記為“音訊”或“專業音訊”，而不是在沒有協調的情況下啟動自己的線程。

此標籤允許 Windows 集中管理這些執行緒的優先權和關聯性 在其特殊音訊模式下，降低了其他子系統在處理緊湊緩衝區時中斷它們的風險。

低延遲驅動程式需要改進

用戶軟體組件只是問題的一半。一個系統要真正發揮作用，還需要更多其他因素。 在特定條件下，緩衝區大小為數毫秒。音訊控制器也必須發揮作用。

從 Windows 10 開始，驅動程式可以透過特定屬性聲明其功能。 每種處理模式支援的絕對最小緩衝區大小此資訊包括一般限制和預設模式、劇院模式等的具體限制。

例如，控制器可能指定絕對最小值為 2 毫秒，但在預設處理模式下，有效大小為 48 kHz 時 128 個樣本（約 3 毫秒）。 音訊堆疊遵循這些限制 絕不會試圖低於規定的最低標準。

除了緩衝區大小之外，還有一些 DDI 可以讓控制器更容易準確地報告。 緩衝區的哪一部分是空閒的，哪一部分已滿，請提供準確的時間戳。 根據效能計數器，在某些情況下，如果您已在內部累積了信息，則可以比實時速度更快地下載資料。

這些功能在具有複雜DSP或記憶體與硬體之間非簡單資料傳輸的設計中尤其有用，因為 流位置和內部延遲取決於幾個中間模組時間戳計算必須考慮這些固定延遲，以便系統能夠​​正確對齊資料。

最後，為了使 Windows 能夠在極低延遲的情況下充分保護音訊子系統， 司機必須向PortCls註冊他們的串流資源：使用中斷及其自身的執行緒來保證資料流。

此註冊可以在驅動程式載入時或運行時完成，並且是強制性的。 串流媒體鏈中的所有控制器 以某種方式參與其中。例如，在具有 HDAudio 匯流排的堆疊中，部分工作由匯流排控制器本身完成，而微型連接埠則註冊自己的執行緒。

用於測量 Windows 延遲的工具和技術

為了確定 WASAPI 調整和驅動程式變更是否確實產生了效果，通常的做法是測量以下指標： 使用揚聲器播放測試脈衝並透過麥克風捕獲來測量往返延遲。軟體會計算傳輸和接收之間的延遲，如果您發現有細微的中斷，就值得檢查一下。 測量DPC延遲 具體來說。

這種方法允許比較不同的緩衝區大小、工作模式和驅動程式版本，前提是音訊設備 接受必要的較小緩衝區範圍否則，系統最終將恢復為預設值 10 毫秒；如需更深入的分析，您可以了解如何操作。 深入分析 Windows 帶有 WPR/WPA。

在配備標準 HDAudio 硬體的系統中， Microsoft 通用 HDAudio 驅動程式 此驅動程式已更新，支援 128 個樣本（48 kHz 時約為 2,66 毫秒）到 480 個樣本（48 kHz 時約為 10 毫秒）之間的取樣大小。在某些情況下，安裝此通用驅動程式可能有助於測試。

這個過程包括打開 設備管理器找到代表內建揚聲器的設備， 強制安裝 Microsoft“高清音訊設備”。 而不是使用製造商提供的編解碼器。重新啟動後，系統將使用該通用驅動程式來驅動該端點。

建議記下先前使用的驅動程序，以便在需要時可以撤銷變更。雖然微軟驅動程式對於試驗較小的緩衝區大小很有用， 廠商提供的版本通常會提供更適合硬體的音質或特定功能。.

WASAPI、AudioGraph 和實際延遲差異

儘管這兩個 API 都依賴相同的音訊引擎，但實際上 AudioGraph 和 WASAPI 在延遲方面的表現並不總是相同的。即使使用相同的底層緩衝區大小。

AudioGraph 的設計初衷是增加一個 在擷取端設定延遲緩衝區，以同步播放和錄製。這大大簡化了應用程式程式碼，因為它確保了兩條路由保持一致，但會增加幾毫秒的時間。

在播放路徑中，當系統使用大於約 6 毫秒的緩衝區大小時， AudioGraph 可以引入另一個安全緩衝區再次提出提供一種模式的想法 程序設計 穩定性好，可預測性強，但延遲稍高。

另一方面，WASAPI 以較少的抽象方式公開路由。這意味著 開發人員需要做更多手工工作。但是，作為回報，它允許您在某些條件下最大限度地減少延遲，尤其是在低頻共享模式和使用 IAudioClient3 時。

此外，與 AudioGraph 不同，WASAPI 允許 更詳細地管理採集效果、原始處理的使用以及與其他 API（例如 Media Foundation）的協調。這為專業專案中的特定優化打開了大門。

在任何情況下，微軟的建議都很明確： 不要輕易使用原始資料處理模式。停用 OEM 特效可以改善延遲，但也可能導致播放訊號或擷取格式最佳化不足，使應用程式難以處理。

如果我們把所有這些碎片拼湊起來，就會清楚地看到馴服之路… WASAPI延遲設置 這需要對 Windows 作業系統堆疊、硬體行為以及可用的 API 有透徹的了解。只有這樣，你才能精準定位每一毫秒的效能提升（或損失），並根據每種應用程式的需求微調配置，同時又不犧牲穩定性或音質。