CPU 使用率明明不高，聲音為什麼會中斷？── 從緩衝區與截止期限來思考

聽音樂時，聲音偶爾會「噗」地斷一下。工作管理員顯示 CPU 使用率只有 10% 上下，偏偏聲音就是不穩定。遇到這種情況，CPU 明明還有餘裕，聲音為什麼還會中斷？

即使 CPU 使用率很低，只要下一批音訊資料沒能在截止期限前補上，聲音就可能中斷。原因在於，必須趁緩衝區裡剩下的聲音還在播放時，把下一批資料交出去。等待資料或鎖定、所需邏輯 CPU 上的 DPC/ISR 等因素造成的補充延遲，就算沒有把整體 CPU 用滿也會發生。Exclusive-Mode Streams、CPU Analysis

不過，光憑聽到的「噗」一聲，還不能斷定是緩衝區不足（underrun）。音源、應用程式、音訊效果、輸出裝置等，也會造成類似的症狀。請先用同一個音源，一次只改一個條件、再改回原狀來比較；如果這樣仍無法縮小範圍，再把斷音前後的狀況記錄下來。Fix distorted or crackling audio in Windows

本文要談的就是這個疑問，以及接下來的「是不是把緩衝區加大就好」「該比較什麼、記錄什麼，才能縮小原因範圍」。本文並不是要只憑 CPU 使用率或聽到的聲音，就確定個別故障的原因。

本文的對象主要是 Windows 11 上的音訊輸出。比較的對象包括內建、有線、USB、藍牙等輸出；至於音樂製作軟體（DAW），也會談到應用程式或驅動程式有提供緩衝區設定時的比較方式。本文沒有全面涵蓋整個錄音系統的設計，也沒有涵蓋各裝置無線通訊的診斷。

說明以共用模式作為基本範例。實際的路徑、緩衝區大小與處理週期，會因應用程式、API、驅動程式與裝置而異，也沒有所有應用程式通用的緩衝區設定畫面。Low Latency Audio

文中的 CPU 使用率、10 毫秒的剩餘量、補充時間點等，都是為了說明而做的假設。這不是在特定電腦上實際量測重現或改善的報告。後半段的操作，是讓讀者在自己的環境中進行的確認步驟。

運作原理可以從下一節「音訊播放緩衝區」開始依序閱讀。調查斷音的操作，則在「比較重現條件」與「用 WPR 記錄斷音」兩節。

圖中實線表示始終成立的關係，虛線表示附帶條件的關係（成立條件寫在詳細頁面中各關係的說明中）。關係的完整清單（共 5 條，附依據與可信度）以及主要概念的定義，彙整在知識地圖詳細頁面（日文）。資料：JSON-LD / Turtle

音訊播放緩衝區

光是把音樂檔存好，喇叭並不會發出聲音。應用程式要準備音訊資料，再透過 Windows 與驅動程式送到輸出裝置。音訊播放緩衝區，是暫時存放接下來要播放之資料的區域。裝置播放目前資料的同時，供應端會準備好下一批資料並補充進去。Rendering a Stream

flowchart TB
    accTitle: 先存一點後面的聲音再播放
    accDescr: 把準備好的音訊資料補充到緩衝區，並在裝置端持續播放的同時準備下一批資料的流程。
    A["準備下一段聲音"] --> B["補充到緩衝區"]
    B --> C["播放已存的聲音"]
    C -.->|"用完之前"| A

圖1：要持續播放，補充的速度必須跟得上聲音的消耗。

圖1 是只呈現補充與消耗關係的概念圖。它並不是把實際音訊路徑上的多個緩衝區，視為實體上同一個區域。Low Latency Audio

緩衝區的作用，是吸收準備聲音的一方與使用聲音的一方之間短暫的時間差，讓播放連續不中斷。不過，緩衝區的容量，和目前裡面尚未播放的資料量是兩回事。「有 10 毫秒的容量」並不代表隨時都剩下 10 毫秒的資料。Rendering a Stream

本文把「必須在播放中的資料用完之前，送達所需的下一批資料」這項時間上的限制，稱為補充期限。音訊處理要求的是「在發聲的時間點之前準備好」。只是「最後總算算完了」並不夠。供應來不及、可播放的資料用盡的狀態，就是緩衝區不足，會造成斷音或喀噠聲。即使資料晚一點送到，也無法事後補回已經聽到的中斷。Exclusive-Mode Streams

音訊資料的路徑

在一般的共用模式下，Windows 的音訊引擎會接收播放應用程式準備好的資料，把多個聲音混合或套用效果之後，再交給驅動程式與輸出裝置。播放應用程式同時負責讀取音源與供應資料給輸出端；驅動程式與輸出裝置則把資料送到裝置端並播放。Low Latency Audio

flowchart TB
    accTitle: 共用模式下音訊資料經過的路徑
    accDescr: 音訊引擎將播放應用程式準備的資料進行混音與效果處理後交給驅動程式，再由輸出裝置播放。
    A["播放程式：準備資料"] --> E["音訊引擎：混音與效果"]
    E --> D["驅動程式：送往裝置"]
    D --> O["輸出裝置：播放"]

圖2：這是共用模式的例子。中間的處理與緩衝區，會因 API 與裝置而不同。

裝置端有時也有自己的處理與緩衝區，整體延遲並不只由應用程式端的緩衝區決定。這裡的說明以共用模式的路徑為前提，並不表示所有 API 都經過相同的處理。Low Latency Audio

剩餘 10 毫秒時的補充

假設緩衝區裡現在還剩下 10 毫秒的未播放資料。如果下一次補充在 8 毫秒後，就能在資料還沒用完時接上；但如果要到 12 毫秒後才能補充，在這個簡化的例子中，資料會在第 10 毫秒時用盡。

flowchart TB
    accTitle: 同樣剩 10 毫秒，補充時間點不同，結果也不同
    accDescr: 以說明用的假設為例：剩餘 10 毫秒的播放資料，若在 8 毫秒後補充就來得及，若在 12 毫秒後補充則已經用完。
    A["剩餘 10 毫秒"] --> B{"下一次補充"}
    B -->|"8 毫秒後"| C["接得上"]
    B -->|"12 毫秒後"| D["第 10 毫秒用盡"]

圖3：這是把時間簡化後的例子。重要的不只是有沒有補上，還有是在什麼時候補上。

CPU 使用率與補充延遲

CPU 使用率呈現的是一段時間內的忙碌程度。它和音訊處理能否在需要的那一刻執行，看的對象並不相同。即使 1 秒內大部分時間 CPU 都有餘裕，只要出現一次 12 毫秒無法補充的區間，這一次的延遲就可能造成中斷。事後剩下的處理能力餘裕，也追不回已經過去的播放時間點。CPU Analysis

flowchart TB
    accTitle: 平均的餘裕與一次補充延遲
    accDescr: 即使 1 秒內大部分時間 CPU 都有餘裕，只要出現一次 12 毫秒無法補充的區間，這一次的延遲就可能讓聲音中斷。
    A["1 秒內大半時間 CPU 有餘裕"] --> B["僅一次 12 毫秒無法補充"]
    B --> C["這一次就讓聲音中斷"]

圖4：即使平均有餘裕，也追不回已經過去的播放時間點。

會吃掉期限內時間的，不只是計算時間。開始處理之前的等待、所需資料送達之前的等待，也都算在內。因此，調查時要問的也不只是「CPU 是百分之幾」，而要改成「聲音中斷的那一刻，下一段聲音在等什麼」。

等待資料與鎖定

假設準備音訊資料的處理，正在等待檔案讀取完成。等待應用程式內其他處理所持有的鎖定時也一樣。正在等待的處理本身幾乎不使用 CPU，但裝置端仍持續播放，剩下的聲音越來越少。Results for the Streaming Media Performance Assessment、CPU Analysis

flowchart TB
    accTitle: 沒有使用 CPU 的等待期間，播放也在繼續
    accDescr: 音訊處理等待資料或鎖定時，該處理不使用 CPU，但播放持續進行、剩餘量逐漸減少，一旦補充延遲，緩衝區就可能用盡。
    A["音訊處理等待資料"] --> B["該處理不使用 CPU"]
    B --> C["這段期間播放仍在進行"]
    C --> D["補充一慢就見底"]

圖5：沒有使用 CPU，不等於必要的工作已經完成。

DPC/ISR 與音訊執行緒

ISR 是回應裝置中斷的處理。DPC 則是為了縮短中斷處理，把剩下的工作延後執行的機制。一般的 DPC 會比同一顆邏輯 CPU 上的一般執行緒優先執行；一般的 DPC 或 ISR 在執行期間，該邏輯 CPU 無法執行一般執行緒。Introduction to DPCs、CPU Analysis

即使 CPU 整體有餘裕，只要這些處理在音訊處理所需的 CPU 上拖得太久或頻繁發生，供應就可能延遲。Microsoft 關於音訊與影片效能分析的文件中，也把網路、儲存裝置、繪圖等驅動程式造成的長時間 DPC/ISR，列為斷音的可能原因。只檢查發出聲音的裝置未必足夠。Results for the Streaming Media Performance Assessment

flowchart TB
    accTitle: 回應裝置的處理拖慢音訊執行的情況
    accDescr: 如果音訊處理所需的 CPU 上，一般 DPC 或 ISR 拖得太久，執行緒的執行就會延遲，並可能影響補充期限。
    A["同一 CPU 上的 DPC/ISR"] -->|"拖太久時"| B["音訊執行被迫等待"]
    B --> C["下一段聲音補充延遲"]
    C --> D["剩餘用盡就斷音"]

圖6：發聲裝置以外的處理，有時也會間接影響音訊的補充。

無法畫出「DPC 只要低於幾微秒，任何電腦都不會斷音」這種共通的界線。效能評估文件中的警告值，是在該評估條件下得出的數值；本文不會脫離實際的補充期限與緩衝區餘裕，把它當成安全基準。Results for the Streaming Media Performance Assessment

緩衝區大小與播放延遲

在相同條件下，預先累積的聲音越多，就越容易吸收暫時的補充延遲；但另一方面，新產生的聲音必須排在已累積的聲音後面等待。只是聽音樂時可以接受的等待，換成彈奏鍵盤，或是把麥克風的人聲加工後自己監聽時，操作與聲音之間的落差就會讓人在意。Exclusive-Mode Streams、Low Latency Audio

flowchart TB
    accTitle: 緩衝區餘裕與反應延遲
    accDescr: 預先累積的聲音增加後，比較容易吸收暫時的補充延遲，但新聲音播放前的等待時間也會增加。
    A["增加預先累積的聲音"] --> B["較易吸收補充延遲"]
    B -->|"代價是"| C["新聲音排在後面等"]
    C --> D["從操作到出聲變慢"]

圖7：加大緩衝區，是用反應速度換取餘裕的調整。

既不是「越小效能越高」，也不是「越大越正確」。要在保留所需反應速度的同時，取得不會中斷的餘裕。

加大緩衝區的調整，是替暫時的供應延遲預留餘裕。如果平均供應本身就跟不上消耗，那麼加大有限的緩衝區也只會延後用盡的時間，同樣解決不了裝置斷線。本文也不是在建議「改用獨佔模式就能解決一切」。Exclusive-Mode Streams

48kHz、480 個音框的音訊

PCM 的音框（frame），是把同一時間點要播放的所有聲道取樣合在一起的單位。並不是因為是立體聲，就要把音框數乘以 2 來計算時間。音框數所代表的聲音長度，以「音框數 ÷ 取樣率」求得；48kHz 下 480 個音框就是 480 ÷ 48000 秒，也就是 10 毫秒。維持 48kHz 而增加音框數，能累積的聲音時間也會變長。Rendering a Stream

這段時間和從按下琴鍵到聽見聲音的總延遲是兩回事。因為還有應用程式、驅動程式、裝置，以及其他緩衝區與處理所花的時間。DAW 的設定值，也要先確認單位與所指的緩衝區再解讀。Low Latency Audio

flowchart TB
    accTitle: 由音框數算出的時間與總延遲
    accDescr: 480 個音框除以 48000 得到的 10 毫秒是緩衝區所代表的時間，再加上應用程式、驅動程式、裝置等的處理，才是從琴鍵到聲音的總延遲。
    A["480 ÷ 48000"] --> B["緩衝區代表的 10 毫秒"]
    B -->|"再加上其他處理"| C["從琴鍵到聲音的總延遲"]

圖8：由音框數算出的時間，只是總延遲的一部分。

比較重現條件

先縮小會重現問題的組合，只在必要時才進入詳細記錄。以下是用來確認原因的步驟，並不是要把所有設定變更一次全部執行的對策清單。

請先儲存手邊的工作，等正式的會議或錄音結束後，再以不會傷耳的音量測試。記下原本的輸出目的地、音訊增強、緩衝區數值等，確保可以改回原狀。沒有提供相應設定的項目就跳過，不要為了叫出設定項目而修改登錄檔等。

1. 決定同一段簡短的音源與觀察時間，在原本的條件下確認是否會重現。

   記錄 Windows 版本、應用程式名稱與版本、輸出裝置、連接方式、驅動程式版本。發生斷音的時間、操作與次數也要留下紀錄。如果在原本的條件下沒有重現，不要判斷為已經改善，而要回頭確認會重現的條件。

2. 從下表選一項比較，只改變該條件來播放。

   要比較的條件	要確認的事
   本機儲存的音源與透過網路播放	是否只在透過網路播放時發生。即使內容相同，若格式或處理路徑不同，也要一併記錄。
   用其他應用程式播放同一音源	是否集中發生在特定應用程式。
   藍牙等輸出與內建、有線輸出	是否集中發生在特定輸出路徑。
   音訊增強的開啟與關閉	是否會因與效果處理的組合而改變。
   DAW 等目前的緩衝區與大一級的值	增加預先累積的餘裕後是否有變化。從操作到出聲的延遲是否也能接受。

3. 比較音訊增強時，在目標輸出上暫時關閉該設定。

   在 Windows 的「設定」→「系統」→「音效」中選擇目標輸出，若環境中有這個選項，就關閉「音訊增強」。如果畫面顯示或項目的有無與此不同，請參考該版本與裝置的說明。Fix distorted or crackling audio in Windows

4. 把變更過的設定改回原狀，用相同的音源與觀察時間再試一次。

   把「原本的條件」「只改一項的條件」「改回原狀的條件」的結果並排比較。沒有效果的變更要先改回原狀，再進行下一項比較。如果不斷變換設定組合，就會搞不清楚到底是什麼發揮了作用。

5. 如果要嘗試更換驅動程式，請先確認官方發布管道與還原方法再進行。

   使用 Windows Update 或裝置製造商官方發布的版本，並記錄變更前後的版本與設定。事先確認能否還原；如果是受管理的電腦，請先和系統管理員討論。不要因為更新後馬上正常播放了一次就視為已解決，而要在相同的重現條件下確認。Fix distorted or crackling audio in Windows

想得到的結果，是像「在這個應用程式中使用這個輸出時會重現」這樣，把症狀與條件連結起來的紀錄。即使找到了能改善的設定，也要和確定原因分開看待。

flowchart TB
    accTitle: 改變一個條件再改回原狀的比較
    accDescr: 用同一音源確認重現，改變應用程式或輸出等其中一個條件，並記錄改回原狀後的結果。
    A["以原組合播放"] --> B["改一個條件播放"]
    B --> C["改回原狀播放"]
    C --> D["記下中斷的條件與時間"]

圖9：比起一次好轉，更要確認條件與症狀能反覆吻合。

改變條件前後的重現性

「症狀壓下來了」「條件縮小了」「找出根本原因了」是不同的階段。要依照實際觀測到的範圍記錄結論。

flowchart TB
    accTitle: 顯示與條件有關的三個結果
    accDescr: 若在原條件下重現、改變一個條件後改善、改回原狀後再度重現，就成為顯示與該條件有關的線索，但要與確定原因分開看待。
    A["原條件下重現"] --> B["改一項後改善"]
    B --> C["改回後再度重現"]
    C --> D["與該條件有關的線索"]

圖10：即使三項都符合，能知道的也只到相關的線索為止。

CPU 使用率低，並不能證明音訊的期限有被遵守。同時，光憑發生了斷音，也不能說補充延遲就是根本原因。要比較音源、應用程式的處理、效果、輸出路徑等，在觀測到的範圍內做判斷。Fix distorted or crackling audio in Windows

採用暫時的因應措施時，要記下原本的設定、變更內容、觀察時間、是否再次發生，以及可接受的延遲。如果根本原因尚未確定，也要把這一點記錄下來。

用 WPR 記錄斷音

這一步適用於光靠條件比較無法縮小範圍，或要調查驅動程式端處理的情況。WPR 是用來錄製的工具，WPA 則是用來分析已儲存時間軸的工具。請準備 Windows Performance Toolkit、錄製所需的權限，以及 ETL 的儲存位置。要在受管理的電腦上安裝工具並錄製時，請委託系統管理員處理。顯示名稱與可用的設定檔，請以安裝的版本為準確認。Windows Performance Recorder

ETL 可能包含處理程序名稱、檔案路徑等資訊。錄製前請確認公司內部規範與分享對象，不要直接附加到公開的地方。如果有其他錄製工作階段正在執行，不要擅自停止，應先向負責人確認。WPR How-to Topics

1. 開啟 WPR 的「More Options」，選擇符合目的的錄製設定檔。

   內建設定檔中有「Audio glitches」與「CPU usage」。請選擇能調查音訊不連續與 CPU 活動的設定。可用的設定檔、顯示名稱與收集內容，請在安裝的版本中確認，也不要設成長時間錄製所有類型。Built-in Recording Profiles

2. 在重現斷音之前就開始錄製。

   如果出現是否停止現有錄製的確認訊息，不要直接繼續，而應取消開始，並向負責人確認。要讓條件與不錄製時一致，同時也要保留「錄製本身的負載可能改變症狀」這個可能性。WPR How-to Topics

3. 以比較時找到的條件播放，記下中斷的時間與操作。

   在症狀前後也包含一小段沒有問題的區間。沒有重現的記錄要明確註記這個事實，不要把它當成捕捉到原因的記錄。

4. 重現之後以「Save」結束錄製，儲存 ETL 檔案。

   按「Cancel」不會儲存。記下儲存位置、重現條件、是否有錄製，以及有無事件遺失的警告。在有遺失的記錄中，不要把看不到的區間判斷為正常。WPR How-to Topics

備齊 ETL 檔案，以及記有斷音時間、操作、條件的筆記後，就完成了在 WPA 中對照的準備。只是儲存了記錄，不代表一定取得了所需的事件。接著在「斷音前後的執行與等待」中確認內容。

flowchart TB
    accTitle: 擷取包含斷音的簡短記錄
    accDescr: 用 WPR 開始錄製，重現症狀並記下時間，停止並儲存後，在 WPA 中檢查記錄。
    A["用 WPR 開始錄製"] --> B["相同條件下重現斷音"]
    B --> C["記下時間與操作後儲存"]
    C --> D["在 WPA 放大前後區間"]

圖11：症狀結束後才看 CPU 使用率並不夠，需要的是症狀發生區間的記錄。

斷音前後的執行與等待

準備好已儲存的 ETL，以及記有重現時間的筆記。以下是在 WPA 中調查的起點。如果需要包含堆疊與符號的詳細分析，請留意記錄的處理方式，並委託系統管理員或開發人員進行。

1. 在 WPA 中開啟 ETL，根據已取得的音訊事件與重現時間，放大斷音前後的區間。

   沒有症狀的區間也要留下來作為比較。不要只看最大值的排名，而要對齊相同的時間範圍來比較。

2. 在同一範圍內查看「DPC/ISR」與「CPU Usage (Precise)」。

   如果沒有需要的資料，請確認所用的設定檔能否取得這些資料，再回到 WPR 的錄製步驟。沒有記錄，和沒有問題是兩回事。CPU Analysis、Built-in Recording Profiles

3. 區分與音訊相關的執行緒，是明明可以執行卻在排隊等候，還是在等待資料等。

   如果是前者，就對照相關的邏輯 CPU 上是否有 DPC/ISR 等長時間執行。如果是後者，就利用已取得的事件與堆疊，追查是什麼解除了等待。由於執行中的執行緒也可能被中斷打斷，不要只看 Ready 的時間，也要把 DPC/ISR 的區間疊在一起看。CPU Analysis

4. 把與斷音的時間對應關係、相關的 CPU、改變條件後的結果一併記錄下來。

   不要只憑長時間 DPC/ISR 的模組名稱，就確定特定裝置或驅動程式是原因。看到的也可能是其他時間點的大數值，或多個裝置共同經過的部分。

flowchart TB
    accTitle: 在斷音區間調查等待的方式
    accDescr: 放大斷音前後的區間，查看音訊執行緒的狀態。若是可執行狀態下的排隊等候，就與同一 CPU 的 DPC 或 ISR 對照；若是等待資料等，就追查解除等待的處理。
    A["放大斷音前後區間"] --> B{"執行緒的狀態"}
    B -->|"排隊等候"| C["DPC/ISR"]
    B -->|"等待資料"| D["解除等待的處理"]

圖12：不要只挑最大值，而要和音訊處理需要執行的區間疊在一起解讀。

如果無法確定，就以「尚未確定」的狀態移交調查。要附上的資訊包括：OS、應用程式、裝置與驅動程式的版本，重現步驟，變更前後的結果，發生時間，收集用的設定檔，以及有無遺失警告。ETL 要依照公司內部規範，只分享給負責調查的對象。

音訊應用程式的預先讀取

自己開發音訊應用程式時，要把填入下一個緩衝區的處理，設計成每次都能趕上期限。WASAPI 提供透過事件接收「可以處理緩衝區的時機」的方法。Exclusive-Mode Streams

MMCSS 是把 CPU 資源分配給有時間限制之多媒體處理執行緒的機制。它沒有預先從磁碟準備資料，或消除鎖定等待的功能。即使利用 MMCSS 的分配，仍需另外做好資料準備與減少等待的設計。Multimedia Class Scheduler Service

flowchart TB
    accTitle: MMCSS 負責的範圍
    accDescr: MMCSS 把 CPU 資源分配給有時間限制的處理執行緒，但資料準備與減少鎖定等待，要靠另外的設計來達成。
    M["MMCSS：分配 CPU 資源"] -.->|"另外需要"| D["資料準備與減少等待"]

圖13：分配 CPU 資源，和讓資料及時到位的設計，是兩件不同的工作。

設計方針是把從檔案或網路讀取的處理，和交付音訊的處理分開。耗時難以預估的準備工作要提前進行，交接時使用事先配置好的緩衝區。音訊這一端要設計成不必等待 UI 的回應、長時間的鎖定或同步的日誌寫入。

flowchart TB
    accTitle: 把耗時難以預估的準備與音訊供應分開
    accDescr: 以預先處理完成讀取等工作，再經由緩衝區把準備好的資料交給音訊處理，藉此減少期限前長時間等待的設計。
    A["預先處理準備資料"] --> B["事先配置的交接區域"]
    B --> C["音訊處理交付所需部分"]
    C --> D["供應給音訊輸出端"]

圖14：把耗時的工作從聲音交接的前一刻移開。

如果準備端長時間停住，即使做了這種分離，存量還是會用盡。不只是平均處理時間，出現長時間處理或等待的那幾次，以及無法供應的次數，也都要用不干擾音訊處理的方式記錄下來。實際選用的緩衝區大小與週期，要透過 API 或驅動程式確認，不要假設指定值會原封不動地被採用。Rendering a Stream、Low Latency Audio

文中的數值範例與設計範例都是為了說明，既不是針對特定裝置的建議設定值，也不保證在任何環境下都不會斷音。

即時優先順序的影響

不建議使用者一律把整個播放器的優先順序改成「即時」。這麼做有妨礙其他重要處理的風險，而且提高一般執行緒的優先順序，也不能消除 DPC/ISR 或等待資料、鎖定的時間。開發時應使用 MMCSS 等機制，以及不把長時間等待帶進音訊供應的設計。Scheduling Priorities、CPU Analysis

flowchart TB
    accTitle: 改成即時優先順序後仍存在的等待
    accDescr: 即使把播放器設為即時優先順序，一般執行緒也無法搶在同一 CPU 上的 DPC 或 ISR 之前，等待資料或鎖定的時間仍然存在，還有妨礙其他重要處理的風險。
    A["播放器設為即時優先順序"] --> B["無法搶在 DPC/ISR 之前"]
    B --> C["資料與鎖定的等待仍在"]
    C --> D["有妨礙其他處理的風險"]

圖15：即使提高優先順序，拖慢音訊補充的等待仍然存在。

相關文章

• Windows 的「處理器排程」與背景服務設定
• 安全地釐清 Windows 磁碟 100% 的原因
• 網路很快，RDP 為什麼還是很卡？

參考資料

• Microsoft Learn, Rendering a Stream。播放緩衝區的資料供應、剩餘量、實際的緩衝區大小，以及 PCM 音框的定義。
• Microsoft Learn, Exclusive-Mode Streams。緩衝區供應的時間點與音訊中斷雜音（glitch）、與延遲之間的取捨、事件驅動的供應。並不是一律建議使用獨佔模式本身。
• Microsoft Learn, Low Latency Audio。Windows 的音訊路徑，緩衝區、裝置、效果處理與延遲，以及低延遲的取捨。
• Microsoft Learn, CPU Analysis。邏輯 CPU、執行緒的 Ready/Waiting、DPC/ISR 與執行緒執行的關係，以及 WPA 的 CPU 分析。
• Microsoft Learn, Introduction to DPCs。縮短中斷處理、把剩下的工作交給 DPC 的機制。
• Microsoft Learn, Results for the Streaming Media Performance Assessment。長時間或頻繁的 DPC/ISR、資料供應不足與音訊中斷雜音。不把評估的警告值推廣為所有裝置的安全基準。
• Microsoft Support, Fix distorted or crackling audio in Windows。音訊增強、格式、驅動程式等的檢查。
• Microsoft Learn, Windows Performance Recorder。ETW 錄製與以 WPA 進行的分析，以及 Windows Performance Toolkit 的使用。
• Microsoft Learn, Built-in Recording Profiles。WPR 的 More Options，以及 Audio glitches、CPU usage 等內建設定檔。
• Microsoft Learn, WPR How-to Topics。開始錄製與以 Save 儲存、與現有工作階段的衝突，以及個人資訊與事件遺失的注意事項。
• Microsoft Learn, Multimedia Class Scheduler Service。將 CPU 資源分配給有時間限制的多媒體處理。
• Microsoft Learn, Scheduling Priorities。處理程序與執行緒的優先順序，以及關於即時優先順序的注意事項。

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

常見問題

整理諮詢這個主題時常見的問題。

CPU 使用率只有 10% 左右，聲音為什麼還會中斷？

音訊有一個期限：必須在播放中的資料用完之前，補上下一批資料。即使 CPU 整體使用率很低，只要音訊處理在那一刻無法執行，或正在等待需要的資料，就可能來不及。並不是所有斷音都出於這個原因，也需要更換輸出裝置或應用程式來比較。

把音訊緩衝區加大，就能解決斷音嗎？

如果補充只是暫時延遲，較大的緩衝區有時能吸收這段延遲。不過，播放已累積的聲音之前的等待時間也會跟著增加。這項設定無法解決處理能力持續不足，也無法解決裝置斷線。若應用程式或驅動程式允許變更，請先記下原本的值，再一次調整一級來比較。

在 48kHz 下，480 個音框是多少毫秒的聲音？

480÷48000 秒，也就是 10 毫秒。PCM 的 1 個音框，是把同一時間點所有聲道的取樣合在一起的單位。這個值是該音框數所代表的聲音長度，不是包含裝置與應用程式在內的總延遲。

DPC 或 ISR 執行時間很長的驅動程式，就是斷音的元凶嗎？

可以列為可疑對象，但光憑執行時間的排名無法確定。要把發生斷音的區間、音訊執行緒的等待，以及同一顆 CPU 上 DPC/ISR 的執行對照來看。不要只憑模組名稱就斷定是特定裝置或驅動程式的缺陷，也要確認改變重現條件後的結果。

把播放器設成即時優先順序，會有改善嗎？

不建議一律這麼做。就算提高一般執行緒的優先順序，也無法搶在同一顆 CPU 上的一般 DPC 或 ISR 之前執行，等待資料或鎖定的時間也不會消失。開發人員應使用 MMCSS 等機制，以及不把等待帶進來的設計；使用者則應先比較重現條件與輸出路徑。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，擅長處理仍留有既有資產的專案，以及原因難以看清的故障調查。