webRTC中音频相关的netEQ（一）：概述

上篇文章（语音通信中终端上的时延(latency)及减小方法）说从本篇开始会切入webRTC中的netEQ主题，netEQ是webRTC中音频技术方面的两大核心技术之一（另一核心技术是音频的前后处理，包括AEC、ANS、AGC等，俗称3A算法）。webRTC是Google收购GIPS重新包装后开源出来的，目前已是有巨大影响力的实时音视频通信解决方案。国内的互联网公司，要做实时音视频通信产品，绝大多数都是基于webRTC来做的，有的是直接用webRTC的解决方案，有的是用webRTC里的核心技术，比如3A算法。不仅互联网公司，其他类型公司（比如通信公司），也会把webRTC里的精华用到自己的产品中。我刚开始做voice engine时，webRTC还未开源，但那时就知道了GIPS是一家做实时语音通信的顶级公司。webRTC开源后，一开始没机会用，后来做OTT语音（APP语音）时用了webRTC里的3A算法。在做了Android手机平台上的音频开发后，用了webRTC上的netEQ，不过用的是较早的C语言版本，不是C++版本，并且只涉及了netEQ中的DSP模块（netEQ有两大模块，MCU（micro control unit, 微控制单元）和DSP(digital signal processing, 信号处理单元)，MCU负责控制从网络收到的语音包在jitter  buffer里的插入和提取，同时控制DSP模块用哪种算法处理解码后的PCM数据，DSP负责解码以及解码后的PCM信号处理，主要PCM信号处理算法有加速、减速、丢包补偿、融合等），MCU模块在CP （communication processor, 通讯处理器）上做，两个模块之间通过消息交互。DSP模块经过调试，基本上掌握了机制。MCU模块由于在CP上做，没有source code，我就从网上找来了我们用的版本相对应的webRTC的开源版本，经过了一段时间的理解后，也基本上搞清楚了机制。从本篇开始，我将花几篇讲netEQ（基于我用的早期C语言版本）。这里需要说明的是每个产品在使用webRTC上的代码时都会根据自己产品的特点做一定的修改，我做的产品也不例外。我在讲时一些细节不会涉及，主要讲机制。本篇先对netEQ做一个概述。）说从本篇开始会切入webRTC中