修正 Android RetroArch 音訊爆裂聲，不掩蓋效能不足
先還原預設同步設定，關閉 shader 與 run-ahead，並在爆裂聲出現時觀察模擬速度。若速度低於核心目標，應先降低工作量；加大緩衝區不會創造不足的 CPU 時間。若速度穩定，再測試裝置喇叭、固定螢幕更新率，以及一次保守的延遲調整，同時保留日誌與可回復的基準設定。
依此順序隔離問題
- 01
記錄 RetroArch 與核心版本、音訊與影像驅動程式、螢幕更新模式、輸出裝置，以及爆裂聲開始的場景。
- 02
還原預設同步與音訊，關閉 shader、run-ahead 和錄影程式，再重新啟動同一份已授權內容。
- 03
觀察速度數分鐘；若速度與爆裂聲同時惡化，先降低核心與影像負荷，再考慮音訊延遲。
- 04
若速度穩定，拔除 Bluetooth 與 USB 音訊後測試裝置喇叭，並核對 Android 媒體音量與音訊焦點。
- 05
使用 RetroArch 測得的螢幕更新率或 Android 固定模式重測，基準測試期間保持 dynamic rate control 開啟。
- 06
只保守調整一次音訊延遲，在裝置升溫後重播同一場景；僅在改善且未增加不可接受延遲時儲存。
證據與下一項測試
| 證據 | 最可能的問題邊界 | 下一步 |
|---|---|---|
| 爆裂聲且速度低於目標 | 核心負荷、影像成本或熱節流 | 關閉效果並測量持續速度 |
| 速度穩定，僅 Bluetooth 爆裂 | Android 路徑、codec 或無線排程 | 先測喇叭，再只接回一個裝置 |
| 速度穩定，影像也週期性停頓 | 更新率／vsync 同步 | 測量更新率並還原 dynamic rate control |
| 只有極低延遲設定失敗 | 音訊緩衝區不足 | 回到上一個穩定延遲值 |
音訊常是最早出現的效能警報
模擬器必須一邊推進機台與輸出影像，一邊穩定提供音訊。若核心無法維持目標速度，緩衝區會耗盡，爆裂聲可能早於明顯的畫面變慢。
應測量核心速度，而不只看顯示 FPS。系統可能在機台時序正確時略過畫格，也可能在模擬已落後時仍顯示畫格。
同步是一套系統，不是一組加速開關
RetroArch 的 dynamic rate control 會協調內容與螢幕之間的細微時差。同時關閉多項同步功能可能只轉移症狀，並造成畫面不均、音高漂移或更高延遲。
先回到預設值、確認實際更新率，再一次更動一層。threaded video 有時能降低驅動程式負荷，但 Libretro 說明了流暢度與延遲代價，因此只應作為有紀錄的替代方案。
Android 應以裝置升溫後的結果為準
Android 裝置可能在熱壓力下限制 CPU 或 GPU。若第一分鐘正常、之後才出現爆裂聲，且速度同步下降，通常指向持續效能邊界。
請在相同電源模式、亮度與背景負載下，等裝置升溫後重測。不要把單一手機的延遲值當成通則；結果必須綁定裝置、輸出路徑、核心與場景。
請使用自己合法擷取的資料、創作者明確授權的內容，或原創測試程式。診斷音訊不需要知名商業遊戲，模擬器設定也不會改變內容權利。