背景
使用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)