遇到這問題後上網查了一下, 結果發現哀鴻遍野, 許多人提到 audio 從播放到真的出來, 有 500ms 的延遲。我以為聲音播放下去應該要立即出來的, 沒想到有這麼嚴重的延遲。
目前沒有對策, 只好從一堆討論中, 挑了幾個比較有代表性的連結備忘:
官方 ticket
- Issue 3434 - android - need NDK support for real-time low latency audio; synchronous play and recordg 這個放了快三年了
- Issue 22517 - android - Audio latency is too high! 這個將標題寫得更清楚, 並 highlight 一下上面那個 issue 沒人理
- 在官方 issues 裡搜 audio latency 或 audio delay 會看到更多相關 issues
其它來源
這兩篇是 2011 年底寫的, 提到最佳 Android 裝置也有 100ms 的延遲, 並且有附聲音和影片展示 audio 延遲是怎麼一回事 (*1)。
- Musique tactile » Android is far behind iOS
- Musique tactile » More thoughts on audio latency in Android
這個站提供測試軟體和各裝置測出來的數據, 這裡有人提到運作的原理是播出聲音後用內建麥克風錄回聲音, 藉此算出 audio delay。以這麼高的延遲時間來說, 應該可忽略計時中間的一些 overhead。我用 Galaxy Nexus 測出來的數據會在 200ms ~ 500ms 之間跳來跳去。
備註
*1 可怕的是, 我習慣這些延遲行為後, 竟然覺得第二個影片的展示感覺還好。這或許也可解釋開發者感受到的問題嚴重程度, 有時不如使用者高, 因為開發者已習慣這樣的表現, 或潛意識覺得這很難處理, 因此反應比較遲頓。
2012-05-26 更新
Scott 在 G+ 上回了不少相關知識, 貼到這裡備忘:（後退一步，講些對你解問題無立即幫助的觀察）
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 了解細節。
沒有留言:
張貼留言