背景

使用webrtc進行語音通話，網絡正常的情況下，延遲比較大。

進行過如下分析：

(1)從socket收包到webrtc處理完音頻沒有耗時長的操作，排除了webrtc處理音頻引入的延遲

(2)與其他終端進行通話無延遲

通過以上的分析，最終確認跟設備有關。分析發現Android設備存在重采用的問題。

重采樣的原因

音頻系統中可能存在多個音軌，而每個音軌的原始采樣率可能是不一致的。比如在播放音樂的過程中，來了一個提示音，就需要把音樂和提示音都混合到codec輸出，音樂的原始采樣率和提示音的原始采樣率可能是不一致的。問題來了，如果codec的采樣率設置為音樂的原始采樣率的話，那么提示音就會失真。因此最簡單見效的解決方法是：codec的采樣率固定一個值(44.1KHz/48KHz)，所有音軌都重采樣到這個采樣率，然后才送到codec，保證所有音軌聽起來都不失真。

但是這樣也引入了一個問題：緩沖區大小越高，音頻越穩定，但延遲越高，緩沖區設置得太小可能會導致CPU過載，因為它必須更加努力地在相同的時間內提供更多的緩沖區，這將導致播放期間出現毛刺。

解決辦法

修改audio_hw.h

將#define SHORT_PERIOD_SIZE (1360*2)修改成

#define SHORT_PERIOD_SIZE (25*2)

總結

以上是生活随笔為你收集整理的java音频采样_音频重采样的坑的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。