教育场景下的实时音频解决方案

本文来自网易云信 资深音频算法工程师 李备在LiveVideoStackCon 2018讲师热身分享，并由LiveVideoStack整理而成。在分享中李备详细分析了在线教育的音频需求，以及通常软件音频框架，和行业的挑战。
你们好，我是来自网易云信的李备，今天我将与你们一块儿探究教育场景下的实时音频解决方案。
本次分享将围绕如下几部分进行：

1. 实时音视频的市场需求

1.1 市场观察
随着我国互联网行业的蓬勃发展与宽带水平的提高，消费者早已不知足于经过简单的文字图片浏览新闻，而是期待经过更佳生动精彩的音视频获取知识了解世界。根据网易云信平台观测的数据，音视频社交应用时长在近两年呈现飞速增加，随之增加的一样还有中国在线教育市场交易规模，从2010年至2017年增加近10倍，并预计在2018～2019年保持增加。
能够说，实时音视频技术助力众多产业转型升级，并使得视频会议等经典应用场景重获新生。众多的新兴场景与行业借助实时音视频技术实现了更佳丰富炫目高效准确的场景表达与业务落地，同时也进一步促进了实时音视频的技术演进与行业探索。实时音视频正在各个千亿、百亿市场快速发展并逐渐成为基础设施型重要技术。
1.2 应用场景

咱们的音视频行业主要存在如下应用场景：以网易公开课为表明的点播，以Finger为表明的直播，以网易云课堂为表明的互动直播与以各类P2P、小班教学、大型培训为表明的实时音视频。

1.3 直播/点播框架
下图展现的是直播与点播的技术框架。

而与上述直播/点播框架不一样的是，互动直播框架更增强调音视频的实时性与强互动性。
来自Web 端连麦观众的音频数据会经过WebRTC网关传输至实时音视频中转服务器，并在此与来自手机连麦观众和PC端主播的音视频数据一块儿由实时音视频中转服务器转发至互动直播服务器。
互动直播服务器会对这些数据作合成/推流处理，传输至融合CDN流媒体服务器，由流媒体服务器推送数据给观看互动直播的普通观众。
与此同时，实时音视频中转服务器一样负责手机连麦观众与PC端主播的直播互动数据交换，从而实现互动直播的效果。

1. 软件层实时音频解决方案

2.1 实时音框架的线程模型与数据驱动方式

上图展现的是实时音频的简单框架线程模型，这里须要提醒的是，其中的解码主要由客户端完成，实时音的服务端不参加解码而是把来自各端的数据包筛选以后传递给其余端。
咱们以音乐教学场景为例，学生与老师正在上课，此时来自学生的音频信号被其移动终端采集模块采集，通过混音消除、降噪、自动增益控制等音频的前处理过程，由音频编码器进行编码。
这里的编码器主要分为专属语音编码器与音乐编码器。音频数据通过编码器的编码处理后会被发送至网络，此时接收端会收到一个缓冲抵抗网络抖动的Jitter Buffer。解码后的音频数据通过快慢速调制与TSM后进行后处理，最后播放。播放时产生的回声会被捕捉并重复上述流程。
在硬件层面，终端制造商对音频处理流程中所须要的硬件都有一套同一切完善的参数调整经验，例如麦克风的采集帧率、拾音距离、回声延迟等都有统一规范；而考虑软件层面的实时音频则需面临设备数量庞大的难题，咱们须要统一海量设备与不一样平台的复杂数据输入而且考虑到软件层面的不可预知性，也就是咱们须要一个完善的音频处理系统，优化各模块之间的协同工做并保证算法的稳定性。所以在这里我向你们展现一下WebRTC线程模型的设计和数据驱动方式：不一样的颜色表明不一样的线程。
首先，音频数据被采集模块采集后进行音频前处理，以后经由交付Buffer被交至音频Codec进行编码。（这里强调的是，咱们不把音频Buffer和Codec放在一个线程的缘由是音频Codec的实时性计算量要求较高，须要单独的一个线程运行。而通过网络发送时通常网络线程是直接将数据传输至Audio Jitter Buff-er，Audio Jitter Buffer获取数据后会在网络线程上接收数据包，并更新网络统计和策略，而playback的callback请求往上回调至Audio Jitter Buffer请求数据过程是运行在Playback的Callback线程上。
通过解码后音频数据会进行TSM、MIX等（若是是处理多路MIX，有些厂家可能会使音频解码单独在一个线程上运行，这一点视应用场景而定，若是是处理一路MIX则能够简单地运行在播放线程上。）关于其中的驱动方式，一些开发者喜欢使用Timer机制驱动数据，但这在实时音频框架中并不推荐。以Audio三维算法处理为例，音频每一帧处理须要大约10毫秒的时间，对时间的精度要求很高；而简单的Timer驱动没法知足这种高精度，尤为是在复杂的系统中很容易出现延迟，这为整个音频处理系统带来的影响无疑是毁灭性的。所以咱们通常采起将驱动运行在系统（回调）中的解决方案，由于系统（回调）的高优先级可确保整个系统的稳定运行。Google就曾经在I/O大会上面推荐把audio process放到系统的采集播放线程里 ；右侧展现的主要有两个系统：收包网络系统与底层的用来驱动音频解码、后处理、MIX的Playback。一个音频引擎框架的稳定性直接决定了其输出声音的质量与实时性。
2.2 音频前处理框架

捕捉到的音频数据会进入Audio 3A处理。其中Audio 3A由AEC、ANS、AGC组成。不一样的应用场景三者的处理顺序也不一样，如在WebRTC中音频数据回依次通过AEC和NS 或者 NS 与AECM（AECM 是WebRTC专门为移动端打造的算法，计算量低，而AEC 是为PC打造的）。
而在AEC(回声消除算法)，为何须要这个算法呢？当一个设备在播放声音通过空间中的屡次反射会被麦克风再次捕捉并采集到系统当中，这时音频的输入既有空间反射的回声也有本端说话声，若是缺乏此模块就意味着通话中说话人一直能够听到本身的声音回来，这是很是差的一种体验，这固然是须要咱们避免的。
这里AEC的做用就是经过播放的参考信号跟踪出回声并从采集信号中把回声消除掉，随后再通过降噪处理去除噪声。而其中的AECM是在NS模块以后经过获取clean与noise数据进行分析，AEC则是NS模块以前直接获取noise数据进行分析。音频数据完成AEC与NS的处理后会进行AGC处理，其包括AAGC（模拟域的自动增益控制）与DAGC（数字域的自动增益控制）。
其中AAGC的主要做用是经过系统的采集音量设置接口调整输入信号（大多用于PC端，移动端通常没有输入音量的系统接口），如借助Windows上的的API调整采集音量等参数。AAGC可为输入的音频数据带来明显的质量优化，如提升信噪比，避免输入信号溢出等。但因为咱们服务的跨平台要求，咱们须要构建一个面向多平台设备的框架，在不一样的输入平台和设备都会有不一样的输入音量，DAGC能够根据对输入信号的跟踪，尽可能的调整信号到达指望大小(幅值或能量)，从而避免不一样设备采集带来的音量差别过大。完成AGC处理的音频数据，便可进入Audio Encode进行编码操做。

这里我想特别介绍一下Audio Jitter Buffer，因为视频的发送码率较高容易对网络形成较大冲击比较大，而音频在窄带与中等码率的情景下的发送码率在50KBPS上下，不会为网络带来较大压力，不少厂家在作音频QOS的时候并不会控制发送带宽(由于宽带的音频带宽不高，对于网络拥塞贡献不大)，而把重点工做都放在接收端的jitter buffer策略上。但咱们的人耳对连续性很是敏感，一旦有包没能及时传递出现丢包，那么观众就可体验到瞬间的卡顿，这种频繁的卡顿会让用户体验大打折扣。
所以咱们须要一个抵抗抖动的Buffer来抵抗网络抖动的冲击，从对Delay要求高、平滑稳定过渡的角度考虑咱们但愿选择较长的Buffer，而从实时性出发咱们又但愿尽量缩短buffer。
为了平衡网络抖动与实时性，咱们引入Audio Jitter Buffer进行处理。通常用来在接收端控制网络抖动，而在不一样模式下采起的抗抖动方案也不尽相同。Jitter Buffer框架与其包含的模块展现在这张图中，其中黄色表明网络线程。Audio Play Callback的数据首先传输至Manager，同时上传一些必要信息，此时音频数据会通过Jitter Policy处理传输至Audio Decode并在播放端触发callback，再由Callback驱动整个抓包流程。JitterBuffer请求包时会根据Jitter Policy进行音频解码或PLC/CNG、Slience等。最后通过后处理与MIX的反复处理，数据被传输至Audio Play Callback。
不一样厂商的Jitter Policy处理方案也不同，如较为出名的WebRTC NeTEQ算法，其中集成了自适应抖动控制算法以及语音包丢失隐藏算法。除此以外， JitterBuffer在跟踪预测准每个包的jitter的时候，也须要考虑实际的缓存播放策略，好比三个包的jitter 分别是100ms，50ms和150ms，若是每次都紧跟预测的jitter，当第一个包来的时候须要缓存100ms，而后第二个包来的时候发现只须要缓存50ms，实际缓存多了须要TSM 调整，直到第三个包来，发现要缓存的又要变化了，又须要须要TSM 调整，那么这样最后的效果将是很是糟糕的。JitterBuffer的目标就是缓存适合的数据能够抵抗网络jitter的抖动，自适应既要兼顾考虑时延，又不能变化过于频繁破坏声音体验，也不能不跟不上网络变化形成缓存不足形成丢包。

1. 行业痛点

音频行业之痛主要是复杂的网络对音频的冲击与碎片化的终端设备背后差距悬殊的硬件。尤为是对Android平台而言，软件层面不一样厂家定制系统的处理流程、硬件层面手机的工业设计、处理器、传感器等都不相同，难以用统一的平台解决方案处理这些设备的音视频问题，主要体如今算法的挑战难度上；与此同时，咱们但愿算法鲁棒性更强，这就意味着须要考虑更多的案例，而算法不可能考虑到全部的案例，咱们必须根据实际状况进行相应取舍……这些都是在将来亟待解决的行业痛点。

想要阅读更多技术干货文章，欢迎关注网易云信博客。
了解网易云信，来自网易核心架构的通讯与视频云服务。

网易云信（NeteaseYunXin）是集网易18年IM以及音视频技术打造的PaaS服务产品，来自网易核心技术架构的通讯与视频云服务，稳定易用且功能全面，致力于提供全球领先的技术能力和场景化解决方案。开发者经过集成客户端SDK和云端OPEN API，便可快速实现包含IM、音视频通话、直播、点播、互动白板、短信等功能。