音樂先解碼為 PCM 取樣，再經過走帶與機架處理，最後交給 Android 音訊輸出。系統與耳機還可能排隊、重新取樣或編碼；某一段緩衝的大小不等於從手指動作到聽見聲音的總延遲。

一個 PCM 影格包含同一時刻各聲道的取樣；處理區塊是一批音訊影格。影格數換算成時間需要取樣率，不能把畫面更新率或一個處理區塊直接當作聽覺延遲。

建議使用有線耳機。開發者對撥輪和搖晃操作的實測中，改用有線耳機解決了藍牙路徑下明顯的可聞延遲；實際反應仍取決於手機、系統與輸出裝置。

前景輸出以裝置最小緩衝需求為下限，並結合約 30 ms 的請求量，減少輸出佇列積壓，讓走帶操作更快反映到後續聲音。

播放最多保留四個預讀視窗，並以按需占用、上限為 16 MiB 的解碼重用快取減少重複解碼，同時限制記憶體使用。預讀與重用不代表把整首曲目或這麼多資料排隊送到耳機。

預讀範圍、解碼結果快取和裝置輸出緩衝各有職責。討論延遲時需要區分這些位置，不能把記憶體容量直接換算成實際輸出延遲。

效果鏈在音訊區塊邊界更新，約 20 ms 的新舊鏈過渡幫助銜接聲音。過渡可能短暫增加處理負載，但不能僅憑此機制認定爆音的原因。Android 只接收一個區塊的部分音訊時，後續繼續提交已處理的剩餘資料，不重複執行效果處理。

旁通會改變聽到的結果，但實例仍會運算以維持狀態。要減少處理負載，應移除暫時不需要的實例。

出現爆音時，先檢查效果鏈輸出峰值、降低過高的效果器增益，排查振幅削波；再移除暫時不需要的效果器，比較處理負載。音訊供給跟不上播放會發生緩衝不足，過高峰值則可能削波。過載燈反映峰值，不能確認緩衝不足；這些步驟有助縮小範圍，不等於確診。

進入背景後，以正常 1 倍速批次提交 PCM 音訊，並保留機架處理。空機架請求約 200 ms 緩衝，有效果器時請求約 600 ms，實際受已配置容量限制。

較大的背景緩衝為系統排程抖動留出餘裕；如果持續處理不及，仍可能欠載。回到前景後恢復較小的緩衝設定，但已排隊的聲音仍需消耗。

撥輪繪製只保留最新狀態，最多一個待繪任務，減少舊狀態積壓。畫面更新與音訊輸出是不同路徑；藍牙造成的可聞延遲不能直接解釋畫面掉幀。

應用程式切到背景、螢幕關閉或關閉對應功能時，停止相應姿態感測器讀取並釋放監聽。動態反光改變光影，不改變聲音；搖晃模擬對聲音的影響由獨立開關控制。

目前公開的是開發者對有線與藍牙輸出的定性觀察，尚未公布具完整條件、可重現的端到端延遲、處理負載或耗電測量數值。

比較這些指標時，需要記錄手機型號、系統版本、輸出裝置與連線方式、取樣率、效果鏈及同一測試片段。請求量和緩衝目標不能代替實測；十個機架位置表示組合容量，不保證任意組合都流暢，也不承諾固定延遲或省電幅度。