Android：OpenSL儘可能低的延遲

我一直在使用OpenSL進行Android的低延遲音頻應用。到目前爲止，我已經設法實現的最低延遲是三星Galaxy S5上的200ms（觸摸到聲音，通過點擊和錄製輕敲聲音，然後是應用聲音來衡量）。我想我可以通過改進一些內部應用程序邏輯將其降至160毫秒。現在接收觸摸的應用程序和獲取該音頻的回調之間存在高達40毫秒的延遲。我認爲這是因爲在沒有音頻時，我經常排隊等待空緩衝區。這是不好的做法嗎？儘管當我嘗試只有在出於某種原因有音頻時才排隊的方法，我仍然會聽到音頻瑕疵。Android：OpenSL儘可能低的延遲

無論如何，我的問題是，使用openSL從觸摸到任何最新的Android設備上的音頻輸出的最低可實現延遲是多少？（我知道它不同於每個設備，但是我想知道什麼是低延遲的最佳設備（如果有的話），這個最低延遲的價值是多少？或者可能是最近設備的平均可獲得的最小值？）。

Android: sound API (deterministic, low latency)

從大約一年前上面的鏈接指出，它是圍繞180ms的範圍內。這仍然是OpenSL的最低可能性嗎？建議的答案是Android的音樂合成器獲得30 ms以下的「總輸出延遲」。但是當我在三星Galaxy S5上運行它時，它會觸發200毫秒的聲音延遲。什麼是指「總輸出延遲」？我錯過了什麼嗎？

如何進一步降低延遲？

感謝您給我的任何幫助！

編輯：我正在做的一切都在Low-latency audio playback on Android除NEON或SSE指令，但我的處理時間少於15％，所以這應該不成問題。我使用2 * PROPERTY_OUTPUT_FRAMES_PER_BUFFER短褲排隊播放立體聲聲音。這太高了嗎？

來源

2014-05-22 Faraz Sherwani

此問題很可能會基於個人使用有限設備的經驗吸引軼事答案，而不是明確正確或錯誤的確切答案。因此它看起來不適合StackOverflow，因爲這不是一個論壇。無論如何，你引用的這些數字聽起來有點高。使用相同的測量方法，當我在一年半前運行延遲測試時，我在XPeria Z上獲得了100毫秒以下的時間。 – Michael

使用openSL？有一些快速模式需要激活嗎？我在排隊的緩衝區中使用了帶有（PROPERTY_OUTPUT_FRAMES_PER_BUFFER * 2）短褲的simplebufferedqueueplayer，對於音頻數據以及播放器使用了PROPERTY_OUTPUT_SAMPLE_RATE。我正在使用立體聲，這就是爲什麼* 2的短褲數量。唯一我能想到的，我沒有做的是使用NEON或SSE指令，但是我的處理時間少於播放時間的15％，延遲仍然很高。 –

看來我正在測試的設備上，Galaxy S5沒有android.hardware.audio.low-latency。這意味着openSL無法使用快速跟蹤，並且會導致高延遲。這真是令人驚訝，因爲該設備非常新，所以它應該支持這樣的新功能。但儘管在我的應用程序中執行了所有必需的低延遲操作，但它將在我正在測試的設備上產生高延遲。

來自android ndk openSL文檔：「這些改進可以通過OpenSL ES獲得，聲稱」android.hardware.audio.low_latency「功能的設備實現。如果設備不聲明此功能，但支持API級別9 （Android平臺版本2.3）或更高版本，那麼仍然可以使用OpenSL ES API，但輸出延遲可能會更高。只有當應用程序請求2或更多的緩衝區計數以及緩衝區大小和採樣率與設備的本機輸出配置兼容。「

對於任何人想知道你的應用是否是問題。請務必檢查您正在測試的設備是否支持此功能。還可以查看（ndk）/docs/opensles/index.html的性能部分以及問題中的鏈接

來源

2014-05-22 18:42:27

多數民衆贊成在令人失望，良好的信息，因爲我正在考慮購買S5 – HaveAGuess

它不支持OpenSL低延遲，但可能有其他方式獲得這些設備，我不知道。 –

有一個audio-echo示例，您可以查看它是否有幫助。當您爲快速音頻創建播放器時，某些信號處理接口不受支持;如果您請求不支持的接口，即使您詢問設備默認採樣率，快速音頻也會關閉。該示例適用於Android L和M [未在其他人測試過]

來源

2015-08-26 00:01:24 Gerry

Android：OpenSL儘可能低的延遲

回答

相關問題