贵阳做网站好的公司,ppt 模板免费下载,新闻最近的新闻,装修设计公司营业执照经营范围背景使用webrtc进行语音通话#xff0c;网络正常的情况下#xff0c;延迟比较大。进行过如下分析#xff1a;(1)从socket收包到webrtc处理完音频没有耗时长的操作#xff0c;排除了webrtc处理音频引入的延迟(2)与其他终端进行通话无延迟通过以上的分析#xff0c;最终确认…背景使用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)
