喇叭測試能告訴我音訊延遲嗎？

不能。喇叭測試透過喇叭播放音調，確認有聲音輸出，它測量的是輸出路徑是否可用，而非訊號經過輸入與輸出鏈路所需的時間。延遲是時間測量，不是功能測試，兩者彼此獨立：系統可能通過所有播放檢查，卻同時存在災難級的延遲。要測量延遲，你需要迴環測試：透過輸出送出已知衝激訊號，在輸入端擷取返回的訊號，並計算發送與接收之間的時間差。

迴環延遲（往返延遲）到底指什麼？

迴環延遲（round-trip latency，也稱往返延遲或往返時間）指音訊訊號從輸入進入系統、經作業系統與應用程式處理後，再從輸出離開的總時間。它包含輸入緩衝區延遲、類比對數位轉換時間、作業系統調度延遲、應用程式處理延遲、數位對類比轉換時間，以及輸出緩衝區延遲，以毫秒計，是麥克風到喇叭的完整路徑。請注意，瀏覽器測得的是透過空氣的聲學迴環，而 ASIO 報告的是內部電氣路徑——兩者不是同一個數字。

我測得的延遲是 80 毫秒，對音樂製作來說糟嗎？

對多數音樂製作而言偏高。跟著伴奏或節拍器演奏的樂手通常偏好 40 毫秒以下的延遲，這樣才能在不感到明顯殘響的情況下準時演奏。80 毫秒的延遲會讓你清楚聽出演奏與回傳聲之間的滯後，要維持精準節拍相當困難。若是隨手錄音或做 Podcast，延遲雖然明顯，通常還能忍受。若是錄音時的即時監聽，80 毫秒基本上不可用。請記得，個人容忍度會因經驗與曲風而異。

為什麼瀏覽器測得的延遲通常比專業音訊軟體高？

瀏覽器的設計目標是跨平台一致性与 Web 應用程式安全，而非專業音訊效能。像 Reaper 或 Ableton 這樣的專業軟體可在 Windows 上使用 ASIO 驅動程式，繞過作業系統的音訊混音層直接存取硬體，通常能達成 8 到 15 毫秒的延遲。瀏覽器則必須經過作業系統共用的音訊層，這會增加混音與調度開銷，而且無法使用低延遲獨佔模式。瀏覽器量到的是共用路徑能達成的最佳成績，在大多數情況下天然高於直接驅動程式路徑——差距則取決於硬體、驅動程式版本與系統設定。

ASIO 驅動程式能降低多少延遲？

在 Windows 上，從預設的 WASAPI 共用模式切換到 ASIO 或 WASAPI 獨佔模式，可以把延遲從 30 到 60 毫秒降到 8 到 15 毫秒。具體降幅取決於音訊介面及其驅動程式實作。ASIO 的原理是讓應用程式直接存取硬體緩衝區，繞過 Windows 音訊混合器與相關的緩衝開銷。不是所有音效卡都支援 ASIO，入門級機板內建音訊通常不支援。在 Windows 上做專業工作，一支支援 ASIO 的音訊介面是延遲層面影響最大的升級之一——但購買前請先想想你的工作流是否真的需要。

更高的取樣率代表更低的延遲嗎？

不直接。取樣率決定音訊每秒被量測多少次，影響頻響與處理開銷，但不影響緩衝區延遲。緩衝區大小才是延遲的主要控制項——緩衝區越小，資料累積到可處理前等待的時間越短。不過，較高的取樣率確實會增加同樣緩衝區大小所需的資料吞吐量，若系統跟不上就會導致緩衝區斷流（underrun）。實務做法是讓取樣率符合工作流，通常是 48 kHz，然後把緩衝區設到最小。

緩衝區大小如何影響延遲與穩定性？

緩衝區大小決定處理前在記憶體中儲存多少音訊取樣。較小的緩衝區降低延遲，但也縮短系統交付下一批資料的時間，提高緩衝區斷流的風險——也就是可聽見的聲音卡住、爆音或中斷。較大的緩衝區更穩定，但增加延遲。最佳點取決於硬體：快速的電腦搭配良好的音訊介面，可以用 64 或 128 取樣的緩衝區獲得低延遲且不卡聲；較慢的系統可能需要 512 甚至 1000 取樣才能穩定。

為什麼藍牙耳機的延遲這麼高？

藍牙音訊編解碼器為了壓縮與無線傳輸會引入相當大的處理延遲。多數裝置預設使用的 SBC 編碼約增加 100 到 180 毫秒延遲，實際數字取決於編碼、裝置緩衝與連結品質（Bluetooth.com: A2DP v1.4 (https://www.bluetooth.com/specifications/)）。就連較高品質的 aptX Low Latency 也只能做到 40 到 80 毫秒（Qualcomm: aptX Low Latency Whitepaper, 2014 (https://www.qualcomm.com/products/aptx)）。延遲是無線協定本身的特性——編碼必須對每一幀進行壓縮、傳輸與解壓縮。任何對時間要求高的應用——音樂製作、遊戲、影片剪輯——在需要精準計時的場合，有線耳機或喇叭才是務實選擇。

音訊迴環延遲：從麥克風到喇叭的往返延遲測試與優化解析

大多數音訊測試只檢查聲音能不能播放、麥克風能不能收音，卻沒有測量迴環延遲——也就是聲音從進入麥克風，到處理後的訊號從喇叭播出的時間。這個數字決定了樂手能否跟著節拍器錄製、視訊通話是否自然，以及遊戲中的空間音訊是否準確。功能與時間是兩個獨立的維度，因此一臺系統可能通過所有播放檢查，卻仍有災難級的延遲。本篇說明如何測量迴環延遲、數字代表什麼，以及如何把它降下來。

所有硬體檢查的開始方式都一樣：插上新的喇叭，播放測試音，確認有聲音輸出，然後進行下一項。插上麥克風，說說話，看著音量表跳動，然後進行下一項。這兩個測試確認你的輸出路徑正常、輸入路徑正常。但沒有任何一個測試會測量那個真正決定你的音訊配置能否勝任實際工作的問題：一個聲音要花多久，才能從麥克風出發、穿過電腦、從喇叭出來？

那個數字就是迴環延遲（round-trip latency），它在背地裡決定你的系統能誠實勝任哪些工作：

錄製音樂。 跟著節拍或伴奏演奏，要求你自己的聲音幾乎即時回到耳中。往返延遲超過大約 40 毫秒，你的節拍就會開始漂移，每一遍錄音都顯得遲鈍，再多的練習也無法修正。與其他裝置共用 USB 控制器的音訊介面也可能受到 USB 頻寬競爭影響，在緩衝延遲之上疊加延遲尖峰。
對話交流。 視訊通話只有在音訊管線保持緊湊時才感覺自然。過大的延遲會產生殘響、重疊的語音，以及衛星電話那種僵硬的節奏。
玩帶空間音訊的遊戲。 定位音效只有在音訊與畫面上看到的同步到達時才有效。當音訊路徑落後於畫面，腳步聲與槍聲就會與屏幕上的動作脫節。

喇叭測試與麥克風測試回答的是「它有沒有用」，迴環延遲測試回答的則是「它有多快」。本頁說明迴環延遲是什麼、從哪裡來，以及如何把它降下來。這裡的數字來自許多硬體與軟體配置的通用經驗——Focusrite Scarlett 2i2 上真實的 ASIO 配置，與 Windows 11 上的 Realtek 內建音效編解碼器，給出的數字會不同。你的結果會隨你的介面、驅動程式與緩衝設定而異。

展示專業音訊介面、耳機與麥克風的錄音室錄製配置，用於延遲測量

音調測試無法測量延遲

喇叭測試透過輸出路徑播放音調、掃頻或音樂樣本，確認有聲音出來。它是一個及格或不及格的功能檢查：線材已連接、驅動程式已載入、音量沒有靜音、數位對類比轉換器還活著。只要你聽得到音調，輸出路徑就是正常的。這是這個測試唯一能告訴你的事。

麥克風測試在輸入方向做同樣的事。它擷取你說的內容、顯示音量表，並確認麥克風、前級放大器和類比對數位轉換器都在正常運作。結果同樣是及格或不及格。

延遲測量是完全不同物種的測試。它問的不是訊號能不能穿過一條路徑，而是穿過去要花多久。程序很簡單：透過輸出送出已知訊號——一個衝激、一聲嗶音、一個短促音節——在輸入端把它擷取回來，計算發送與接收之間的時間差。那個差值就是迴環延遲，以毫秒表示。

這個區別之所以重要，是因為這兩種測量彼此獨立。系統可能通過所有播放測試，卻同時存在災難級的延遲。藍牙喇叭是經典例子：它能忠實重現音調，所以喇叭測試報告成功，而無線編解碼器增添的 100 到 180 毫秒延遲，沒有任何播放測試會察覺。一個晚到 150 毫秒的音調，嚴格來說依然在播放。

這就是為何常見的假設——「我的喇叭聽起來沒問題，所以我的音訊系統也沒問題」——對任何時間敏感的工作都會崩潰。功能與時間是兩個獨立的軸。在你把配置用於錄製、通話或遊戲之前，你需要那個播放測試在結構上無法產生的數字。

觀察緩衝區如何填滿

迴環延遲不是一個單一的延遲，而是麥克風振膜與喇叭振膜之間每一階段累積延遲的總和。理解這條路徑，就能精確知道你的毫秒藏在哪裡：

輸入緩衝區。 類比對數位轉換器持續取樣，但作業系統以區塊方式交付音訊。驅動程式會等一個緩衝區填滿，才把資料交給應用程式。在 48 kHz 下，128 取樣的緩衝區填滿需要 2.7 毫秒——這就是你的音訊在被任何人處理前的等待時間。多數系統同時保留兩到三個緩衝區在飛行中。預計你的應用程式看到第一個取樣前，大約有 5 到 8 毫秒。
類比對數位轉換。 轉換器需要時間來取樣、量化並對訊號時鐘。消費級硬體在此通常貢獻 1 到 3 毫秒；專業介面能做得更好。
作業系統調度。 音訊引擎用計時器喚醒你的應用程式，喚醒本身要受正常的執行緒調度影響。在共用模式下，作業系統還會把你的音流與系統中所有其他音訊來源混音，加上它自己的一輪處理。這一段的貢獻從幾毫秒到 20 毫秒以上不等，取決於平台與負載。這正是搭載 PipeWire 的 Linux 能超越 Windows 的階段——也是一個嘈雜的桌面環境能悄悄把你的延遲吹爆的階段。
應用程式處理。 接收端的軟體——數位音訊工作站、效果鏈、瀏覽器的音訊圖——在往下傳遞之前處理這個區塊。份量小，但仍是總和的一部分。
數位對類比轉換。 第二階段的鏡像，當處理後的訊號變回類比電壓時，再增加 1 到 3 毫秒。
輸出緩衝區。 處理好的取樣在輸出緩衝區中等待，直到轉換器準備好播放它們，重複輸入端那套緩衝區大小的計算。在典型配置中，再增加 5 到 8 毫秒。

把各階段加總，普通電腦上共用模式的迴環延遲通常在 30 到 60 毫秒之間——以下的測量數字是特定硬體的示意範例，不是通用規格。在一台出廠原狀、配備 Realtek ALC897 音效編解碼器、128 取樣緩衝區的 Windows 11 筆電上的非正式測試中，觀察到共用模式的測量值落在這個區間的偏高端。在同一硬體上用 Behringer U-Phoria UM2 搭配 ASIO4ALL，測量值則降到接近 15 毫秒。這些是沒有受控條件的單機觀察，用作共用模式與 ASIO 路徑之間典型差距的參考點，不是對你的硬體的保證值。沒有任何驅動程式能消除轉換時間——但佔據總和大部分的緩衝與調度開銷，卻能大幅縮小。

展示迴環音訊延遲路徑的示意圖：從麥克風經過電腦處理到喇叭輸出

一個數字，兩種定義

音訊軟體很少只引用一個數字。打開專業應用程式的設定，你通常會看到兩個：輸入延遲，從麥克風到應用程式的時間；輸出延遲，從應用程式到喇叭的時間。ASIO 這類驅動程式會分別報告兩個數值，而行銷資料常引用看起來較好的那一個。

迴環延遲是兩者相加，再加上應用程式自身的處理時間。如果一個系統標稱單向 20 毫秒，往返大約就是 40 毫秒。讀到「20 ms 延遲」就以為那是自己將聽到的延遲的使用者，錯了整整一倍——而這個錯誤很常見，因為規格表上印的正是單向數字。

這個區別之所以重要，是因為你感知到的永遠是往返。當樂手監聽自己的聲音或樂器時，聲音必須離開麥克風、穿過系統、回到耳機，他們才能聽見。那才是完整的路徑；單向數字只描述了旅程的一半。

為了讓討論保持一致，本文所有數字都指迴環延遲。當你把自己的測量值與產品規格或基準測試比較時，務必確認兩個數字描述的是同一種旅程。拿往返測量去對單向規格，會讓你的系統看起來比實際慢一倍。

作業系統先於你做出決定

同一支麥克風、同一副喇叭、同一條線，在不同作業系統上會產生天差地別的延遲，因為每個平台都把音訊送到不同的軟體堆疊。堆疊決定在無法避免的轉換時間之上，會加多少緩衝與調度開銷。

Windows：共用模式、獨佔模式與 ASIO

Windows 提供三種抵達硬體的方式，每種都有不同的延遲特徵：

WASAPI 共用模式是所有應用程式的預設路徑，除非它們另有所求（Microsoft Learn: WASAPI Shared Mode, 2023）。所有音訊混在一起，以保守的緩衝交付。典型系統上觀察到的迴環延遲常見區間為 32 到 64 毫秒，取決於緩衝區大小與負載——這些是常見經驗區間，不是保證值。Web Audio、WebRTC 與媒體播放各自走略不同的路徑，但都始於這個共用混音器。
WASAPI 獨佔模式或 ASIO繞過混音器，把裝置的直接存取權交給單一應用程式，在典型硬體上通常能把延遲降到約 10 毫秒（Microsoft Learn: WASAPI Exclusive Mode, 2023）。它對提出請求的 native 應用程式開放；瀏覽器無法使用。
ASIO是一個完全繞過 Windows 音訊堆疊、直接與介面硬體溝通的驅動程式協議（Steinberg: ASIO Host and Driver Guide v2.3, 2021）。搭配能力足夠的介面，ASIO 常見能達成 8 到 15 毫秒，但精確數字取決於具體介面、驅動程式版本與緩衝設定。瀏覽器無法使用它。

macOS：Core Audio

Apple 的 Core Audio 架構優化得相當好，native 應用程式在合理的緩衝設定下，通常能達到 8 到 20 毫秒的迴環延遲。共用路徑效率高，所以 macOS 上連瀏覽器測得的延遲通常都比 Windows 好。它仍高於 native 下限，因為瀏覽器無法宣示獨佔裝置存取，也無法依自身需求調整緩衝區。

Linux：ALSA、PulseAudio 與 PipeWire

Linux 的延遲是流動的目標。ALSA——低層驅動介面——很快，但綁定特定應用程式。PulseAudio 歷史上會在上面增添明顯的緩衝開銷。現代替代品 PipeWire 為低延遲音訊而設計，正確設定下可與其它平台匹敵甚至更優，但結果因發行版與配置而異，變化很大。

在多數配置中，瀏覽器被限制在共用路徑內。它無法請求獨佔模式、無法載入 ASIO 驅動程式、也無法調高自己的音訊執行緒優先級。因此瀏覽器音訊延遲通常接近平台共用模式的上限——協作路徑在標準配置下能提供的最好成績——而 native 專業軟體的架構，正是在硬體與驅動允許時脫離那個上限。

60 毫秒到底代表什麼

裸的毫秒數字，在你把它對上你要做的事之前沒有任何意義。以下的界限是一般性指引，不是專業認證標準；實際適用性取決於你的具體任務、監聽配置與聽音環境。四個區間涵蓋實務範圍：

低於 20 ms——優秀。 專業音樂製作在這裡相當舒適。樂手可以跟節拍錄音、戴效果監聽自己、準時演奏，因為回傳路徑幾乎是瞬時生效。遊戲中的空間音訊緊貼視覺。
20–60 ms——適合大多數用途。 Podcast、視訊通話、一般遊戲與隨手錄音都能運作良好。緊密的音樂錄音在這個區間的上段開始吃力：樂手會感覺自己的聲音回傳略有拖曳，超過大約 40 毫秒後，精細工作的難度明顯上升。
60–120 ms——對製作有問題，對休閒用途可接受。 卡拉 OK、語音聊天與聽音都沒問題。跟伴奏錄製會變得真正困難，遊戲中的音訊開始與動作脫節，削弱空間音訊所依賴的定位線索。
超過 120 ms——差。 時間敏感的工作基本上不可能。通話出現可聽見的回音，演出感覺脫節，空間音訊連休閒使用都聽起來不對。這個區間是藍牙音訊與設定不良的共用模式系統的自然棲息地。

區間邊界是判斷題，但整體形狀是可靠的：製作需要最低的數字，對話能容忍更多，休閒聽音容忍最多。你的迴環測量把你的系統放在其中一個且只有一個區間，而那個位置會告訴你哪些預定用途會感覺舒適、哪些會跟你對抗。把這個數字記下來——它是下一節所有優化的參考點。

以顏色編碼顯示可接受音訊延遲區間的圖表：從低於 20ms 的專業級到超過 120ms 的不適用

三個槓桿：取樣率、緩衝區、驅動程式

三個控制項決定你的延遲落在路徑的哪個位置，而它們的影響並不對等。

取樣率設定管線的吞吐量——音訊每秒被量測多少次——而非直接決定延遲。它確實與緩衝計時互動，因為緩衝區以取樣計量：128 取樣在 44.1 kHz 下需要 2.9 毫秒，在 96 kHz 下只要 1.3 毫秒，所以同樣的緩衝區大小在不同取樣率下對應不同的時間長度。陷阱在於更高的取樣率要求每秒更多的處理，這常常迫使你把緩衝區調回較大以維持穩定，把收益抵消掉。追著 96 或 192 kHz 跑，通常為了讓音流穩定而被迫使用更大的緩衝區，可能抵消理論上的收益，甚至變得更慢。把取樣率當作工作流設定來用，通常 48 kHz，不要把它當成延遲的主要控制項。48 kHz 成為視訊同步音訊的事實標準，是因為它能乾淨地對齊 24、25、30 fps 的影片幀率，專業音訊影片管線也因此預設用它。

緩衝區大小是延遲的主要槓桿。它決定系統處理前累積多少音訊，而且它在往返中出現兩次——輸入端一次、輸出端一次。緩衝區減半，那部分延遲也減半，但系統交付每個區塊的時間也減半，緩衝區斷流（underrun）的風險上升：卡聲、爆音與中斷。在 48 kHz 下的實務矩陣長這樣：

64 取樣——在支援 ASIO 或獨佔模式的合格硬體上，往返約 8–12 ms。入門介面在這個大小下常出卡聲。
128 取樣——約 12–20 ms。製作上常見的 ASIO 甜蜜點。
256 取樣——約 20–35 ms。常是共用模式下最小的穩定值。
512 取樣——約 35–60 ms。安全，但明顯拖泥帶水。
1024 取樣——約 60–100 ms。只適合延遲無所謂的串流或播放。

驅動程式設定下限。ASIO 與獨佔模式允許 32 到 128 取樣的緩衝區大小；共用模式的下限更高；藍牙編解碼器在緩衝區還沒被考慮之前就先加 100 毫秒以上。任何緩衝區調整都打不敗驅動程式的下限，所以驅動程式是第一個槓桿，不是最後一個。

瀏覽器不是 DAW

瀏覽器可以用 Web Audio API 估算迴環延遲（MDN: Web Audio API, 2024）：它排程一個衝激訊號通過輸出，再在麥克風輸入端擷取到達的訊號。在共用模式下的筆電上，典型的 Web Audio 迴環測量常見報告 55–70 ms——是 ASIO 數字的數倍——這個差距正是瀏覽器「共用路稅」的寫照。測得的時間包含透過空氣的聲學路徑、喇叭與麥克風的換能器、房間的殘響消除處理，以及整個系統音訊堆疊。這被稱為聲學往返延遲，對瀏覽器內的通話、卡拉 OK 與瀏覽器遊戲而言，它是相關的數字，但不等同於專業音訊軟體測量的 ASIO 迴環延遲。請記得，這個測量需要喇叭與麥克風之間真實的聲學路徑；自動音量控制、噪音抑制與殘響消除可能改變衝激的形狀，而麥克風距離、房間反射與音量設定都會影響結果。

瀏覽器做不到的是抵達硬體的最好情形。它必須使用作業系統的共用音訊路徑、無法宣示獨佔裝置存取、無法載入 ASIO 驅動程式、也無法控制自己的音訊緩衝區大小或執行緒優先級。因此測量反映的是平台共用模式的上限，而非硬體的真實下限。

而那個上限，對瀏覽器內的工作來說正是恰好的數字。Web 通話、瀏覽器遊戲、Web 卡拉 OK，以及任何在分頁中運作的東西，在 OS 層面共用同一條瀏覽器音訊路徑，只是 Web Audio、WebRTC 與媒體播放細節不同。如果瀏覽器測得的數字好，所有瀏覽器用途都會感覺好。如果它差，native 軟體可能還救得了你——但在同一硬體與配置下，瀏覽器通常比 native 軟體慢。

六種降低延遲的方法

按影響大小排序處理問題，數字落入你能接受的區間就停手：

先搞定驅動程式模式。 在 Windows 上，為你的音訊介面安裝 ASIO 驅動程式，或切換到 WASAPI 獨佔模式。這是最單一的巨大槓桿，而且免費。
降低緩衝區大小。 從 512 逐檔降到 256、128、64 取樣，每檔都試，直到聽見卡聲或爆音。然後往回升一檔，停在保持乾淨的最大緩衝區。
檢查取樣率。 音樂與影片工作用 48 kHz。追著 96 kHz 或 192 kHz 跑通常反而被迫用更大的緩衝區，最後更慢。
關閉競爭的應用程式。 串流、擷取與忙碌的瀏覽器分頁會搶走音訊執行緒的 CPU 時間，在小緩衝區下造成斷流。
考慮買一支音訊介面。 專用硬體帶來更好的轉換器、正牌的 ASIO 驅動程式，以及內建音訊達不到的緩衝區大小。
優先使用有線連接。 對任何時間敏感的工作，有線耳機比藍牙快 100 毫秒以上，與其它任何設定無關。

每一步都是複利效果。從共用模式 512 取樣換到 ASIO 128 取樣，系統常見從 50 毫秒移到 20 毫秒以下——這是不可用與專業之間的差距。

結論

播放測試確認你的喇叭能用。迴環測試確認它們準時——這是兩個不同的問題，有不同的答案。執行喇叭測試驗證輸出路徑，執行麥克風測試驗證輸入路徑。請注意本站目前不提供專屬的迴環延遲測量工具；上述 Web Audio API 的方法需要另行實作或瀏覽器主控台設定。用它來了解那項決定你的機器上錄製、對話與空間音訊是否自然的聲學往返延遲。

測一次，把結果留著。低於 20 毫秒代表專業級的計時。20 到 60 涵蓋大多數日常工作。超過 120，每個時間敏感的任務都會跟你對抗，而解法通常從驅動程式開始，不是從硬體開始。如果你從未測量過那個數字，你對所有依賴計時的音訊工作都只是在猜。