背景

使用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 (256*2)