Android 的 audio delay

遇到這問題後上網查了一下, 結果發現哀鴻遍野, 許多人提到 audio 從播放到真的出來, 有 500ms 的延遲。我以為聲音播放下去應該要立即出來的, 沒想到有這麼嚴重的延遲。

目前沒有對策, 只好從一堆討論中, 挑了幾個比較有代表性的連結備忘:

官方 ticket

其它來源

這兩篇是 2011 年底寫的, 提到最佳 Android 裝置也有 100ms 的延遲, 並且有附聲音和影片展示 audio 延遲是怎麼一回事 (*1)。

這個站提供測試軟體和各裝置測出來的數據, 這裡有人提到運作的原理是播出聲音後用內建麥克風錄回聲音, 藉此算出 audio delay。以這麼高的延遲時間來說, 應該可忽略計時中間的一些 overhead。我用 Galaxy Nexus 測出來的數據會在 200ms ~ 500ms 之間跳來跳去。

備註

*1 可怕的是, 我習慣這些延遲行為後, 竟然覺得第二個影片的展示感覺還好。這或許也可解釋開發者感受到的問題嚴重程度, 有時不如使用者高, 因為開發者已習慣這樣的表現, 或潛意識覺得這很難處理, 因此反應比較遲頓。

2012-05-26 更新

ScottG+ 上回了不少相關知識, 貼到這裡備忘:

(後退一步,講些對你解問題無立即幫助的觀察)

1. 在簡單的 interrupt driven PCM samples 播放運作中,系統 wakeup 次數與 audio delay 成反比。故增加 audio latency 可省電。

2. 漂亮的解法是應用可以隨需要將系統調成 interrupt 與 polling mode,且 polling 時可調整 timer interval 的觀念,寫一個『latency 需求低時省電,有 app 需要 low latency 時才常 wakeup 以達成 low latency』的系統,如:http://0pointer.de/blog/projects/pulse-glitch-free.html

3. 這是 Android 將 Linux userspace 全部砍掉重練的後遺症,desktop Linux 反而無『latency 與 power consumption traodeoff』問題:http://arunraghavan.net/2012/01/pulseaudio-vs-audioflinger-fight/

Apple 在 OSX 原本就有 low latency / soft realtime 的 audio API 所以 iOS 也比較了解、有顧到這邊的需求。

4. 各個 Android 裝置 audio delay 會不同是因為 audio codec 晶片廠商與手機系統廠有在測『播音樂、電影時系統電池可撐多久』。且 Android 靠近 audio device driver 這部份的架構讓他們可以微調,但這些廠商隨手也寫不出 timer based audio scheduling,軟體架構上鼓勵他們改的也只是『專屬於某硬體』的部份。

2013-07-13

情況總算有些進展, 見 Google I/O 2013 - High Performance Audio 了解細節。

留言

這個網誌中的熱門文章

(C/C++ ) 如何在 Linux 上使用自行編譯的第三方函式庫

熟悉系統工具好處多多

virtualbox 使用 USB 裝置