造成音訊延遲的因素

本頁重點介紹輸出延遲的影響因素,但類似的討論也適用於輸入延遲。

假設類比電路貢獻不大,那麼音訊延遲的主要表面影響因素如下:

  • 應用
  • 管道中的緩衝區總數
  • 每個緩衝區的大小(以幀為單位)
  • 應用處理器之後的額外延遲,例如來自 DSP

儘管上面的貢獻者清單可能很準確,但它也具有誤導性。原因是緩衝區計數和緩衝區大小更多的是結果而不是原因。通常發生的情況是,實現並測試給定的緩衝區方案,但在測試期間,音訊欠載或溢出會聽到“咔噠”或“彈出”聲。為了補償,系統設計者隨後增加緩衝器大小或緩衝器計數。這具有消除欠載或超載的預期結果,但也具有增加延遲的不良副作用。有關緩衝區大小的更多信息,請參閱視訊音訊延遲:緩衝區大小

更好的方法是了解欠載和超載的原因,然後進行修正。這消除了可聽的偽影,並且可以允許更小的或更少的緩衝區,從而減少延遲。

根據我們的經驗,欠載和超載的最常見原因包括:

  • Linux CFS(完全公平調度器)
  • 使用 SCHED_FIFO 調度的高優先權線程
  • 優先權反轉
  • 調度延遲長
  • 長時間運行的中斷處理程序
  • 中斷禁止時間長
  • 能源管理
  • 安全內核

Linux CFS 和 SCHED_FIFO 調度

Linux CFS 旨在公平地對待共享公共 CPU 資源的競爭工作負載。這種公平性由每個執行緒的nice參數來表示。 Nice 值的範圍從 -19(最不良好,或分配最多的 CPU 時間)到 20(最好,或分配最少的 CPU 時間)。一般來說,具有給定nice值的所有執行緒都會收到大致相等的CPU時間,而具有數值較低nice值的執行緒應該會收到較多的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音訊執行緒。

速率單調調度

有關固定優先級分配理論的更多信息,請參閱維基百科文章速率單調調度(RMS)。關鍵點是固定優先順序應嚴格根據週期分配,將較高優先順序分配給週期較短的線程,而不是基於感知的「重要性」。非週期性線程可以使用最大執行頻率和每次執行的最大計算量來建模為週期性線程。如果非週期性執行緒無法建模為週期性執行緒(例如,它可以以無限頻率執行或每次執行無限計算),則不應為其分配固定優先權,因為這與真正週期性執行緒的調度不相容。

優先權反轉

優先權倒置是即時系統的經典故障模式,其中較高優先權的任務被無限期地阻塞,等待較低優先權的任務釋放資源,例如互斥鎖(受共享狀態保護)。請參閱文章「避免優先倒置」以了解減輕這種情況的技術。

調度延遲

調度延遲是指執行緒準備好運行與上下文切換完成以便執行緒實際在 CPU 上運行之間的時間。延遲越短越好,任何超過兩毫秒的時間都會導致音訊問題。較長的調度延遲最有可能發生在模式轉換期間,例如CPU的啟動或關閉、安全核心和普通核心之間的切換、從全功率模式切換到低功耗模式或調整CPU時脈頻率和電壓。

中斷

在許多設計中,CPU 0 服務所有外部中斷。因此,長時間運行的中斷處理程序可能會延遲其他中斷,特別是音訊直接記憶體存取 (DMA) 完成中斷。設計中斷處理程序以快速完成並將冗長的工作推遲到執行緒(最好是優先順序為 1 的 CFS 執行緒或SCHED_FIFO執行緒)。

同樣,長時間停用 CPU 0 上的中斷與延遲音訊中斷服務具有相同的結果。長時間的中斷禁用時間通常發生在等待核心自旋鎖時。檢查這些自旋鎖以確保它們是有邊界的。

功率、性能和熱管理

電源管理是一個廣泛的術語,涵蓋在優化性能的同時監控和降低功耗的工作。熱管理電腦冷卻相似,但尋求測量和控制熱量以避免因過熱而造成損壞。在Linux核心中,CPU調控器負責低階策略,而使用者態則配置高層策略。使用的技術包括:

  • 動態電壓調節
  • 動態頻率縮放
  • 動態核心啟用
  • 集群交換
  • 電源門控
  • 熱插拔(熱插拔)
  • 各種睡眠模式(暫停、停止、空閒、掛起等)
  • 行程遷移
  • 處理器親和力

某些管理操作可能會導致「工作中斷」或應用程式處理器不執行任何有用工作的時間。這些停工可能會幹擾音頻,因此此類管理應針對音頻處於活動狀態時可接受的最壞情況停工而設計。當然,當熱失控迫在眉睫時,避免永久性損壞比音訊更重要!

安全內核

用於數位版權管理(DRM)的安全核心可以在與用於主作業系統核心和應用程式程式碼的應用程式處理器核心相同的應用處理器核心上運行。安全核心操作在核心上處於活動狀態的任何時間實際上都會停止通常在該核心上運行的普通工作。特別是,這可能包括音頻作品。就其本質而言,安全核心的內部行為對於更高層級的層來說是難以理解的,因此由安全核心引起的任何效能異常都特別有害。例如,安全核心操作通常不會出現在上下文切換追蹤中。我們稱之為「黑暗時間」──流逝卻無法被觀察到的時間。安全核心的設計應考慮到音訊處於活動狀態時可接受的最壞情況的停工。