即时通讯开发之如何测试实时语音通话质量

实时语音聊天开发，对于一般的开发者来说比较神秘，很多朋友不太清楚如何全面的评估一个音频引擎。很多朋友还停留在这样的初级阶段：把demo调通，找几个人喂喂喂......凭自己优异的听觉感受一下，整个测试过程就完成了。

但是，少年！如果就这么简单，你很有可能遇到下面的这些坑：

    我们花了好多钱买了一套基于硬件的解决方案，开始用的还行，怎么现在越来越卡了？
    我们评估了某个引擎，自己内网测试的时候感觉声音很流畅，延时很小。为什么上线了很多用户说又卡又延时啊？
    我们用WebRTC做了一套方案，iPhone上还好，但是为什么在安卓的机器上老是有回声啊？
    为什么我昨天用的还好好的，今天换了个手机/地方/网络打效果差好多啊？

如何科学的测试语音通话质量，这是本文提纲：

    首先，普及一下，哪些因素会影响对音频质量的评估。
    然后，我们再来看需要做哪些测试。
    {BANNED}最佳后，我们讨论一下大家比较关心的WebRTC框架中的音频模块如何，是否适合商用？

网络对音频质量的影响是非常直观的，如果承载音频信息的语音包在网络传输的过程中丢失，晚到，或者不均匀的到，就会造成我们常说的丢包，延时和抖动。

从主观听感上造成声音的卡顿和滞后，严重影响通话的质量和可懂度。在公共互联网上，特别是在远距离通信的情况下，如果缺乏足够的网络部署和音频的丢包对抗技术，这种情况就会变得尤为明显。如果是在内网环境，两人通话的场景下，声音可以通过点对点（P2P）的连接互相传输，很多网络问题容易被单一的测试环境忽略了。这也是为什么有些同学在自己的公司内网测试时候感觉延时小声音流畅，跑到真实环境下就经常遇到各种各样的质量问题。

另外值得一提的是，除了在传输层引起的丢包抖动，{BANNED}最佳后一公里(Last Mile)的问题（路由器，移动数据网络等）也会引起丢包抖动，所以有时候有的同学说我们家20M的带宽，怎么用起来还是卡顿。其实有时候是因为你家路由器太破了。

设备对于音频质量的影响是相对隐性的，但是往往会起着决定性的作用。

iPhone就有着比较好的声学设计：

    麦克风和扬声器之间的耦合程度较小：
    这样你说话经扬声器播放产生的回声，在被麦克风收录时候已经有了很大程度的衰减，对回声消除模块来说也是一个利好。
    另外它有三个麦克风：
    位于设备底部的麦克风，主要收取说话人的声音；位于背部的麦克风，用来拾取背景噪声，给主麦克风做参考，从而更好对人声做降噪处理，让对方听得更清楚；位于听筒附近的麦克风，用来感知听筒附近的噪声，从而生成一个反相位的波从听筒里播放出来抵消这部分噪声，让你听对方也可以听的更清楚。即时通讯聊天软件app开发可以加蔚可云的v：weikeyun24咨询

但是，设备的问题在安卓机上就非常碎片化，所有和安卓打过交道的开发者都没少听过适配这两字。由于每个设备扬声器和麦克风的属性都不尽相同，特别是在一些中低端机型上，声学设计是非常不合理的（严重的麦克风扬声器耦合，非线性失真，麦克风底噪等），会使得一些通用的音频算法（回声消除，降噪）无法正常工作。这也回答了我们之前的问题，为什么有些同学测的iPhone觉得不错，但是到一些中低端的安卓机器上就问题百出。这类问题无论网络好坏都会产生，这时候就必须有音频引擎的算法模块来做对应的算法适应和适配了。

除此之外，在手机这类非实时操作系统上，计算资源的抢占，录放音的调度问题都会对音频算法带来很大的挑战。要解决这些问题就必须投入大量的资源去研发和调试，而解决这类问题的技术门槛一般都是很高的。

物理环境对音频的影响更不容易被察觉，但是它在很多情况下会干扰到音频引擎的正常工作，从而对用户的{BANNED}最佳终听感产生负面影响。熟悉音频算法的朋友都知道，我们在做回声消除的时候，需要实时估计出当前物理环境的脉冲响应(Impulse response)，才能将它和参考信号(Reference signal)卷积，从而初步估算出麦克风收到的回声信号。

假设我们现在身处一个密闭的会议室，扬声器播放出来的回声部分，在被麦克风收录时，就会掺入很多物理环境反射路径带来的分量，这个时候就要考察自适应滤波器是否有足够的能力来覆盖这种场景了。如果音频引擎做得不好，就会导致我们平时遇到的一些奇怪现象：比如为什么我刚才听对方好好的，他换了个小会议室继续开会，我就听到很多奇怪的杂音呢？事实上，影响脉冲响应的因素远不止这些，甚至有研究发现每一度温度的变化可能会导致40dB脉冲响应的变化。

另外还有很多物理环境会对音频质量造成影响，举例：

    近场时候的尖锐杂音（啸叫），是由于设备A的麦克风会直接收录到设备B的扬声器播放的声音，然后又会传回设备B播放出来，形成了一个正反馈回环导致的。只要分开一定距离通话或者静音掉其中一方就会消失。
    本地身处嘈杂的环境下的听对方会更困难，对方听自己也会有受到噪声的干扰。
    刚才说的密闭环境下，本身想保留的语音信号也会受到反射路径的影响，造成平时所说的混响(Reverb), 会让对方听到一些失真。
    网络，设备和物理环境都会对音频质量造成很大的影响，而且这种影响很多时候并非很直观的可以察觉到。如果没有科学的评估和定量的分析，很难通过一两次测试来下比较全面和准确的结论。

下一节会告诉你：我们需要怎样来定量和全面的评估一个音频引擎呢？要做哪些测试才能覆盖到尽量多的真是使用场景，同时又能尽可能的排除各种随机的影响因素呢？

我们想要定量的分析一个音频引擎的优劣点，就必须在测试中尽可能的排除网络、设备和物理环境等因素带来的随机性影响。3GPP、ESTI等通信业国际标准，对手机通信的测试环境方法很多要求和指引，感兴趣的同学可以在参考文献找到一些资料。

简单的说，我们需要：

    专业设计的消声室：我们需要足够安静且反射路径{BANNED}最佳小化的声学环境来避免周围的环境音来影响测试。
    人工耳和人工嘴：我们需要可重复又高保真的发声和收音装置来覆盖人的正常说话和听力动态范围。
    网损设备：为了覆盖更多的真实场景，我们需要网损设备来模拟和控制丢包。
    近似真实环境的沉浸式噪音场景：我们需要在人工头的四周布置高保真的音箱来制造噪声声场。

要执行符合3GPP，ETSI等通信标准的客观测试，我们需要搭建了类似下图的测试环境。以Head Acoustic的ACQUA系统为例，我们需要：

    将被测设备(DUT)置于消声室内，根据听筒，耳机和外放模式对应的标准距离和方法固定被测设备。
    参考设备(RD)放在消声室外，通过Line-in线从测量前端(MFE)输入标准的语音序列。
    做发送端的测量时，DUT接收到人工嘴的语音信号，经过对应的音频模块和网络传输处理，由消声室外的RD收到解码并送入MFE计算得分。
    做接收端的测量时，参考信号由MFE灌入RD，经过网络传输被DUT收到解码播放，人工耳记录下从DUT播放出来的声音与参考信号比较计算得分。
    网损模拟装置控制在发送端或者接收端加入不同类型的丢包，延时和抖动，来测量不利网络环境下的引擎表现。
    背景噪声模拟装置在消声室环境中制造不同信噪比和噪声类型的环境噪声，测试音频模块的降噪效果。

在业界，音频主观测试并没有可以统一遵循的标准。虽然ITU对音频主观测试有一些建议和指引，但是每个测试都有自身的侧重点设计和执行也不尽相同。一般比较常用的做法是请足够多的人来采集有统计意义的样本，然后对测试人员做一定的听音培训。{BANNED}最佳后根据信号失真度，背景侵入度，和总体质量等方面来对音频通话打分。

这种方法主要用来比较不同引擎之间的总体主观感受，如果需要更细节的发现和比较问题，还是需要跟针对性的测试。

主观测试相对来比较灵活，可以不必限定在消声室中进行。但是为了尽量避免我们之前的提到的设备网络环境的不确定因素，测试人员和被测设备需要分别放置于两个音源隔离的房间。网损的部分，可以使用Linux的TC NetEM模块模拟，如10%丢包设置命令为：tc qdisc add dev eth0 root netem loss 10%。 噪声的部分，如果没有ACQUA等分析系统提供的噪声源，可以使用NOISEX-92等学术研究中常用的语料库来代替。建议对通话进行录音，这样可以在测试后重听和标注，更好的分析问题。如果测试的引擎不带录音的话，可以在外放的而环境通过外部设备来录制。

一般我们先在较好的网络状态下测试音频的基础质量，然后慢慢增加丢包率来测试一个引擎抗丢包的边界。另外在细节的音频模块方面也需要很多针对性的测试，比如回声消除，降噪，增益控制，近场啸叫，盲源分离等模块都可以有非常详细的细节指标可以跟踪。

下图（a）和（b）比较了两款实时音频引擎（为了避免广告嫌疑，我们以引擎A和引擎B命名）在降噪（NS）方面的表现。这里用的是NOISEX-92语料库中的Voice Babble，混音的信噪比是5dB。 通过录音和定量分析，我们可以看到在算法的收敛时间，降噪后的残留噪声，和有语音时候的信噪比方面，引擎B的音频引擎效果有明显的优势。