聲音不是直達耳朵

你在視訊會議裡說完一句話，對方卻像晚了半拍才聽見；你按下電鋼琴的一個鍵，聲音彷彿在追趕手指。這種不對勁不一定是網路問題。有時候，聲音正在電腦、手機或瀏覽器裡排成一小列。

直接答案是：系統通常不會把剛收到的每一小段聲音立刻送進喇叭。它會先把幾小段放進緩衝區。緩衝區像一個很小的等候盒：盒子裡有存貨時，播放裝置就不必每一瞬間都等應用程式送來下一段聲音；但盒子越長，聲音從產生到被聽見的路也越長。

假設你按下一個數位鋼琴鍵。軟體先產生一段數位聲音，接著把它切成很多很短的聲音片段，再交給作業系統與輸出裝置。輸出裝置依自己的節奏取走片段，讓耳機或喇叭發聲。這條路上不只一個人交班：應用程式、音訊系統、裝置驅動與硬體都有自己的時間。

因此，「我剛剛產生聲音」和「第一個聲音樣本真的變成空氣振動」不是同一件事。W3C 的 Web Audio 規格把送入音訊子系統的處理延遲稱為 baseLatency，也另列出從系統要求播放到裝置實際處理樣本的 outputLatency。規格刻意把這些時間分開，因為它們來自不同的交班位置。

小盒子先解決一個尷尬問題

如果播放裝置每次都在原地等下一段聲音，任何很短的延遲都可能造成空隙：排程晚了一點、某段運算卡了一下、裝置還沒準備好，喇叭就會暫時沒有資料可播。人耳聽到的未必是一個整齊的錯誤訊息，而可能是爆音、斷裂、雜音，或一句話像被咬掉一角。

緩衝區的用途不是把聲音加工得更好聽，而是先備一點存貨。播放端取走一段，同時應用程式補上一段。只要補貨速度大致追得上取貨速度，聲音就能連續。Android 的 AAudio 文件也把這個關係說得很具體：緩衝區容量決定可放多少資料，而實際填入的大小會影響需要幾次資料傳送才能填滿；這也直接改變延遲。

短隊伍：手感靠近，餘裕變薄

把盒子做得很小，代表新產生的聲音不用等太久。這對即時演奏、節奏遊戲、即時監聽或要把說話聲立刻回送給自己的情境很重要。讀者按下按鍵後，若聲音與動作相隔太遠，節奏感會先被破壞。

但是，小盒子的餘裕很薄。只要下一批資料晚來，盒子就可能被拿空。Android 的低延遲文件把這種情況稱為 underrun：緩衝區太小時，可能發生雜訊或斷裂；官方建議不要猜一個通用大小，而是依裝置回報的 burst 與實際 underrun 情況調整。這不是越小越專業的競賽，而是要把等待縮短到仍能穩定補貨的位置。

長隊伍：聲音平穩，回應繞遠

把盒子做得較長，播放端就有比較多存貨可以消耗。應用程式偶爾慢一點，聲音仍可能平順地繼續。對一段已經錄好的影片、背景音樂或不需要立刻回話的播放來說，這份餘裕往往比極短反應更重要。

代價也很直白：盒子裡已經排好的片段要先播完，新聲音才能輪到出口。你按下按鍵、移動控制器或說出一句話時，這個動作若排在隊尾，就得等前面的片段離開。較長的緩衝區不是錯，只是把系統優先順位從立刻回應改成盡量不斷。

同一台機器，
也沒有一個固定答案

延遲不是某個軟體單獨決定的數字。聲音的取樣率若和輸出裝置不同，系統可能還要重新取樣；W3C 規格明確指出，這會影響實際延遲。不同裝置的硬體與作業系統也會回報不同的最佳取樣率、每次傳送的影格數與緩衝條件。Android 文件因此要求應用程式讀取裝置回報值，而不是把某個看似漂亮的數字寫死。

這也解釋了為什麼同一個程式在兩台手機上可能感覺不同。它們不是一定有誰做錯，而是在不同的取貨速度、補貨時間與硬體路徑上協調。真正需要追求同步時，程式必須量測自己所在的那條路，而不是拿別人的毫秒數當保證。

把聲音放進對的隊伍

Web Audio 把延遲偏好分成 interactive、balanced 與 playback 等方向：前者傾向降低輸出延遲，後者傾向讓連續播放更不容易被打斷。這些不是三個神奇模式，而是同一個選擇的三種語氣：你是希望下一個聲音快點到，還是希望現在這段不要斷？

所以，遇到慢半拍時，第一個問題不必是怎樣把緩衝區壓到最小。更實用的問題是：這個聲音需要立刻回應，還是需要長時間平穩？即時演奏要先保護手感；長片播放要先保護連續；兩者之間再用實測找一個不會常常見底的隊伍長度。

聲音不是沿著一條空管子直接跑進耳朵。它先被切成小段，在一個看不見的盒子裡等待輪到自己。那點等待有時讓人覺得慢，卻也是讓聲音不必每次遇到一點遲到就碎掉的原因。理解這個小盒子，才知道更快和更穩其實是在替不同時刻的聽感排隊。