共计 3191 个字符，预计需要花费 8 分钟才能阅读完成。
文|网易智慧企业资深客户端开发工程师
年初因为工作须要，开始学习 WebRTC，被其简单的编译环境和微小的代码量所折服，注定是一块难啃的骨头。俗话说万事开头难，保持一个恒心，究竟能学习到 WebRTC 的设计精华。
明天和大家聊聊 WebRTC 中音频的那些事。WebRTC 由 语音引擎，视频引擎和网络传输 三大模块组成，其中 语音引擎是 WebRTC 中最具价值的技术之一，实现了音频数据的采集、前解决、编码、发送、承受、解码、混音、后处理、播放等一系列解决流程。
音频引擎次要蕴含：音频设备模块 ADM、音频编码器工厂、音频解码器工厂、混音器 Mixer、音频前解决 APM。
音频工作机制
想要零碎的理解音频引擎，首先须要理解 外围的实现类和音频数据流向，接下来咱们将简略的剖析一下。
音频引擎外围类图
音频引擎 WebrtcVoiceEngine 次要蕴含音频设备模块 AudioDeviceModule、音频混音器 AudioMixer、音频 3A 处理器 AudioProcessing、音频治理类 AudioState、音频编码器工厂 AudioEncodeFactory、音频解码器工厂 AudioDecodeFactory、语音媒体通道蕴含发送和承受等。
1.音频设备模块 AudioDeviceModule次要负责硬件设施层，包含音频数据的采集和播放，以及硬件设施的相干操作。
- 音频混音器 AudioMixer次要负责音频发送数据的混音（设施采集和伴音的混音）、音频播放数据的混音（多路承受音频和伴音的混音）。
- 音频 3A 处理器 AudioProcessing次要负责音频采集数据的前解决，蕴含回声打消 AEC、自动增益管制 AGC、噪声克制 NS。APM 分为两个流，一个近端流，一个远端流。近端（Near-end）流是指从麦克风进入的数据；远端（Far-end）流是指接管到的数据。
- 音频治理类 AudioState蕴含音频设备模块 ADM、音频前解决模块 APM、音频混音器 Mixer 以及数据流转核心 AudioTransportImpl。
- 音频编码器工厂 AudioEncodeFactory蕴含了 Opus、iSAC、G711、G722、iLBC、L16 等 codec。
- 音频解码器工厂 AudioDecodeFactory蕴含了 Opus、iSAC、G711、G722、iLBC、L16 等 codec。
音频的工作流程图
1. 发动端通过麦克风进行声音采集
2. 发动端将采集到的声音信号输送给 APM 模块，进行回声打消 AEC，乐音克制 NS，自动增益管制解决 AGC
3. 发动端将解决之后的数据输送给编码器进行语音压缩编码
4. 发动端将编码后的数据通过 RtpRtcp 传输模块发送，通过 Internet 网路传输到接收端
5. 接收端承受网络传输过去的音频数据，先输送给 NetEQ 模块进行抖动打消，丢包暗藏解码等操作
6. 接收端将解决过后的音频数据送入声卡设施进行播放
NetEQ 模块是 Webrtc 语音引擎中的外围模块
在 NetEQ 模块中，又被大抵分为 MCU 模块和 DSP 模块。
MCU 次要负责做延时及抖动的计算统计，并生成对应的管制命令。
而 DSP 模块负责接管并依据 MCU 的管制命令进行对应的数据包解决，并传输给下一个环节。
音频数据流向
依据下面介绍的音频工作流程图，咱们将持续细化一下音频的数据流向。将会重点介绍一下 数据流转核心 AudioTransportImpl 在整个环节中表演的重要角色。
数据流转核心 AudioTransportImpl 实现了采集数据处理接口 RecordDataIsAvailbale 和播放数据处理接口 NeedMorePlayData。
RecordDataIsAvailbale负责采集音频数据的解决和将其散发到所有的发送 Streams。
NeedMorePlayData负责混音所有接管到的 Streams，而后输送给 APM 作为一路参考信号处理，最初将其重采样到申请输入的采样率。
RecordDataIsAvailbale 外部次要流程：
- 由硬件采集过去的音频数据，间接重采样到发送采样率
- 由音频前解决针对重采样之后的音频数据进行 3A 解决
- VAD 解决
- 数字增益调整采集音量
- 音频数据回调内部进行内部前解决
- 混音发送端所有须要发送的音频数据，包含采集的数据和伴音的数据
- 计算音频数据的能量值
- 将其散发到所有的发送 Streams
NeedMorePlayData 外部次要流程：
- 混音所有接管到的 Streams 的音频数据
1.1 计算输入采样率 CalculateOutputFrequency()
1.2 从 Source 收集音频数据 GetAudioFromSources(), 选取没有 mute，且能量最大的三路进行混音
1.3 执行混音操作 FrameCombiner::Combine()
- 特定条件下，进行噪声注入，用于采集侧作为参考信号
- 对本地伴音进行混音操作
- 数字增益调整播放音量
- 音频数据回调内部进行内部前解决
- 计算音频数据的能量值
- 将音频重采样到申请输入的采样率
- 将音频数据输送给 APM 作为一路参考信号处理
由上图的数据流向发现，为什么须要 FineAudioBuffer 和 AudioDeviceBuffer？
因为 WebRTC 的音频流水线只反对解决 10 ms 的数据，不同的操作系统平台提供了不同的采集和播放时长的音频数据，不同的采样率也会提供不同时长的数据。
例如 iOS 上，16K 采样率会提供 8ms 的音频数据 128 帧；8K 采样率会提供 16ms 的音频数据 128 帧；48K 采样率会提供 10.67ms 的音频数据 512 帧。
AudioDeviceModule 播放和采集的数据，总会通过 AudioDeviceBuffer 拿进来或者送出去 10 ms 的音频数据。
对于不反对采集和播放 10 ms 音频数据的平台，在平台的 AudioDeviceModule 和 AudioDeviceBuffer 还会插入一个 FineAudioBuffer，用于将平台的音频数据格式转换为 10 ms 的 WebRTC 能解决的音频帧。
在 AudioDeviceBuffer 中，还会 10s 定时统计一下以后硬件设施过去的音频数据对应的采样点个数和采样率，能够用于检测以后硬件的一个工作状态。
音频相干改变
1. 音频 Profile 的实现，反对 Voip 和 Music 2 种场景，实现了采样率、编码码率、编码模式、声道数的综合性技术策略。iOS 实现了采集和播放线程的拆散，反对双声道的播放。
2. 音频 3A 参数的兼容性下发适配计划。
3. 耳机场景的适配，蓝牙耳机和一般耳机的适配，动静 3A 切换适配。
4. Noise_Injection 噪声注入算法，作为一路参考信号，在耳机场景的回声打消中的作用特地显著。
5. 反对本地伴音文件 file 和网络伴音文件 http&https。
6. Audio Nack 的实现，进步音频的抗丢包能力，目前正在进行 In-band FEC。
7. 音频解决在单讲和双讲方面的优化。
8. iOS 在 Built-In AGC 方面的钻研：
（1）Built-In AGC 对于 Speech 和 Music 无效，对于 noise 和环境底噪不会产生作用。
（2）不同机型的麦克风硬件的增益不同，iPhone 7 Plus > iPhone 8 > iPhone X; 因而会在软件 AGC 和硬件 AGC 都敞开的状况下，远端听到的声音大小体现不一样。
（3）iOS 除了提供的可开关的 AGC 以外，还有一个 AGC 会始终工作，对信号的 level 进行微调；猜测这个始终工作的 AGC 是 iOS 自带的 analog AGC，可能和硬件无关，且没有 API 能够开关，而可开关的 AGC 是一个 digital AGC。
（4）在大部分 iOS 机型上，外放模式“耳机再次插入后”，input 的音量会变小。以后的解决方案是在耳机再次插入后，减少一个 preGain 来把输出的音量拉回正常值。
音频问题排查
和大家分享一下音频最常见的一些 景象以及起因：
以上就是我对于语音引擎的一些分享，欢送大家留言与我探讨。
