本頁主要說明輸出延遲的影響因素，但輸入延遲的討論也類似。
假設類比電路並未造成明顯影響，那麼造成音訊延遲的主要表面因素如下：
- 應用程式
- pipeline 中的緩衝區總數
- 每個緩衝區的大小 (以影格為單位)
- 應用程式處理器 (例如 DSP) 後的額外延遲時間
雖然上述貢獻者清單可能正確，但也可能會造成誤解。原因是緩衝區計數和緩衝區大小是效果，而非原因。通常會實作並測試特定緩衝區配置，但在測試期間，音訊不足或超出會聽起來像「喀嚓」或「啪」的聲響。為彌補這項缺點，系統設計人員會增加緩衝區大小或緩衝區數量。這會帶來預期的結果，也就是消除執行時間不足或超時的情況，但也會帶來不必要的副作用，也就是增加延遲時間。如要進一步瞭解緩衝區大小，請參閱「音訊延遲：緩衝區大小」影片。
比較好的做法是瞭解不足和超出的成因，然後加以修正。這麼做可消除可聽見的雜訊，並且可能允許更小或更少的緩衝區，進而縮短延遲時間。
根據我們的經驗，造成短時間和超時的常見原因包括：
- Linux CFS (Completely Fair Scheduler)
- 使用 SCHED_FIFO 排程的高優先順序執行緒
- 優先順序反轉
- 排程延遲時間長
- 長時間執行的中斷處理常式
- 長時間中斷停用時間
- 電源管理
- 安全核心
Linux CFS 和 SCHED_FIFO 排程
Linux CFS 的設計目的，是為了公平對待共用通用 CPU 資源的競爭工作負載。這種公平性會以每個執行緒的 nice 參數表示。nice 值的範圍為 -19 (最不優先，或分配最多 CPU 時間) 到 20 (最優先，或分配最少 CPU 時間)。一般來說，所有具有指定優先順序值的執行緒，都會獲得大致相同的 CPU 時間，而數值較低的執行緒，則應獲得較多的 CPU 時間。不過，只有在觀察時間較長的情況下，CFS 才會「公平」。在短期觀察期間，CFS 可能會以非預期的方式分配 CPU 資源。舉例來說，它可能會將 CPU 從數值較低的優先順序執行緒移至數值較高的優先順序執行緒。在音訊方面，這可能會導致播放時間不足或超時。
顯而易見的解決方法，就是避免在高效能音訊執行緒中使用 CFS。從 Android 4.1 開始，這類執行緒現在會使用 SCHED_FIFO 排程政策，而非由 CFS 實作的 SCHED_NORMAL (也稱為 SCHED_OTHER) 排程政策。
SCHED_FIFO 優先順序
雖然高效能音訊執行緒現在使用 SCHED_FIFO，但仍可能受到其他優先順序較高的 SCHED_FIFO 執行緒影響。這些通常是核心工作處理序，但也可能有幾個使用政策 SCHED_FIFO 的非音訊使用者執行緒。可用的 SCHED_FIFO 優先順序範圍為 1 到 99。音訊執行緒會以 2 或 3 的優先順序執行。這樣一來，優先順序 1 可供優先順序較低的執行緒使用，而優先順序 4 到 99 則可供優先順序較高的執行緒使用。建議您盡可能使用優先順序 1，並將優先順序 4 至 99 保留給可保證在限定時間內完成的執行緒，這些執行緒的執行週期比音訊執行緒的週期短，且已知不會干擾音訊執行緒的排程。
以費率為準的排程
如要進一步瞭解固定優先順序指派的理論，請參閱維基百科的「Rate-monotonic scheduling」(RMS) 一文。重點是，應嚴格依據週期分配固定優先順序，並將較高的優先順序指派給週期較短的執行緒，而非依據感知到的「重要性」。非週期性執行緒可模擬為週期性執行緒，使用執行的最大頻率和每次執行的最大運算。如果非週期性執行緒無法以週期性執行緒的形式建模 (例如，執行緒可能以無限頻率執行，或每次執行時會進行無限計算)，則不應指派固定優先順序，因為這會與真正的週期性執行緒排程不相容。
優先順序反轉
優先順序反轉是即時系統的經典失敗模式，其中較高優先順序的工作會在無限時間內遭到阻斷，等待較低優先順序的工作釋出資源，例如 (由共用狀態保護的) 互斥鎖。如要瞭解如何減輕優先順序反轉的影響，請參閱「避免優先順序反轉」一文。
排程延遲時間
排程延遲是指執行緒準備就緒到實際在 CPU 上執行的時間差。延遲時間越短越好，超過兩毫秒就會導致音訊問題。長時間的排程延遲最有可能發生在模式轉換期間，例如啟動或關閉 CPU、在安全核心和一般核心之間切換、從全電力切換至省電模式，或調整 CPU 時脈頻率和電壓。
中斷
在許多設計中，CPU 0 會服務所有外部中斷。因此，長時間執行的中斷處理常式可能會延遲其他中斷，特別是音訊直接記憶體存取 (DMA) 完成中斷。設計中斷處理常式，以便快速完成並將長時間的工作延遲至執行緒 (最好是 CFS 執行緒或 SCHED_FIFO 執行緒，優先順序為 1)。
同樣地，在 CPU 0 上停用中斷的時間越長，延遲處理音訊中斷的結果就會越相似。長時間的中斷停用時間通常會發生在等待核心 旋轉鎖時。請查看這些旋轉鎖定機制，確保它們受到限制。
電源、效能和熱管理
「電源管理」一詞涵蓋的範圍很廣，包括監控及降低耗電量，同時提升效能的努力。溫度管理和電腦散熱雖然類似，但前者旨在測量及控制溫度，避免因過熱而損壞。在 Linux 核心中，CPU 節流器負責低階政策，而使用者模式則會設定高階政策。使用的技術包括：
- 動態電壓調整
- 動態頻率調整
- 啟用動態核心
- 叢集切換
- 電源管制
- 熱插拔 (熱插拔)
- 各種休眠模式 (停止、停止、閒置、暫停等)
- 程序遷移
- 處理器相依性
部分管理作業可能會導致「工作停止」或應用程式處理器在某些時間內沒有執行任何有用的工作。這些工作中斷可能會干擾音訊，因此應針對音訊處於活動狀態時，可接受的最糟情況工作中斷情形設計這類管理機制。當然，如果即將發生熱失控，避免永久性損壞比音訊更重要！
安全核心
數位版權管理 (DRM) 的安全核心可在與主要作業系統核心和應用程式程式碼相同的應用程式處理器核心上執行。安全核心作業在核心上啟用時，任何時間都會有效停止通常在該核心上執行的一般工作。這類內容可能包括音訊作品。安全核心的內部行為本質上是無法從較高層級檢視，因此安全核心造成的任何效能異常都特別有害。舉例來說，安全核心作業通常不會顯示在內容切換追蹤記錄中。我們稱之為「黑暗時間」(dark time)，也就是經過一段時間卻無法觀察到的時間。安全核心應設計為在音訊啟用時，可接受最糟糕的停工情況。