又被“过运营商语音认证”虐了一回

又被“过运营商语音认证”虐了一回！虐的伤痕累累、疲惫不堪！过程是痛苦的，但结果是美好的，收获也是挺多的！既然用了“又”，那之前确定被虐过。是的，没错。那是7年多前（2011年末），一样是在秋冬，不过一个是2011年末，一个是2018年末。一样是在芯片公司， 不过一个是老牌外企，一个是本土新秀。当时咱们在公司的芯片上作了一个语音通讯解决方案（具体怎么作的见我前面的文章：如何在嵌入式Linux上开发一个语音通讯解决方案），只有过了中国电信的语音认证客户才会用咱们的。老板把这个任务交给了我，我那时是第一次弄这些，一脸懵逼。既然交给了我，我就尽全力把它作好。认证主要有两方面内容：音质相关的MOS（Mean Opinion Score，平均主观意见分）和时延相关的delay。当时MOS的评分标准是PESQ(Perceptual Evaluation of Speech Quality，语音质量的感知评估)，即ITU-T的P.862。通过近几年的发展，现在变成了POLQA（Perceptual Objective Listening Quality Analysis，感知客观语音质量评估），即ITU-T的P.863。P.863标准（POLQA）是对P.862标准（PESQ）的升级，适应范围更广，评价结果更接近主观的MOS。通过近三个月的努力，成功过了认证，内心别提多高兴了。虽然很累，但技术能力提升了很多，也特别有成就感。此次过的是中国移动（CMCC）手机上的EVS音频电学认证。关于EVS，我在前面的文章（移动通讯最早进的音频编解码器EVS及用好要作的工做）中讲过。下面就讲讲是怎么过认证的以及怎么被虐的。

 

前面的文章（Android智能手机上的音频浅析）讲了安卓手机上音频相关的软硬件，文章（谈谈我开发过的几套语音通讯解决方案）讲了在安卓手机上打传统电话时的方案，知道了通话时主要是CODEC芯片、Audio DSP（ADSP）和CP参与语音数据的传输，具体以下图：

codec芯片主要负责语音的采集和播放，ADSP上主要是编解码以及语音加强（voice Enhancement，简称VE，包括AEC、ANS、AGC等）等，CP上主要是网络侧及空口的处理。CMCC之前对EVS是可选项，但2018年四月份开始变成了必选项，即要入库的手机必定要支持EVS。咱们公司的手机芯片是支持EVS的，这功能是我和CP的同事共同完成的（我负责Audio DSP上EVS codec相关的，CP同事负责网络侧IMS相关的）。那时中国移动关于EVS认证的case还没公布，咱们在实网下对EVS作了基本的调测，能用了。到了七八月份具体case公布了，全面调测EVS就提上了日程。CP同事、测试同事和我三人组成了一个小分队，因为EVS codec在Audio DSP上，这件事就由我来牵头向前推动。先在实网下作全面的测试，解决了很多语音质量相关的问题（好比噪声断续等）。这些问题相对都是较难弄的，花了近一个月。实网下测下来基本感受不到噪声断续等问题了，咱们决定开始过移动EVS认证的case。

 

CMCC EVS音频电学认证的case也主要分两类：MOS和delay。测试时仪器经过音频线和手机的耳机孔链接进行语音数据的传输，仪器经过射频线和手机上的射频口相连进行空口数据的传输，其框图以下：

MOS有良好网络下的上下行MOS、恶劣网络下的下行MOS、LTE向2/3G切换的切换中和切换后的MOS、数据业务并发时的MOS等。算上行MOS时，仪器把参考音频经音频线送给手机，手机上行处理后经射频线再把码流送给仪器，仪器解码码流获得PCM再基于POLQA（上面说过如今MOS的评分标准用的是POLQA）跟参考音频比较获得MOS分，上图中的uplink方向给出了示意。算下行MOS时，仪器把参考音频的码流经射频线送给手机，手机下行处理后经音频线把语音再送给仪器，仪器基于POLQA把收到的语音跟参考音频比较获得MOS分，上图中的downlink方向给出了示意。Delay一样有良好网路下的delay、恶劣网络下的delay、LTE向2/3G切换的切换先后的delay、数据业务并发时的delay等，这里delay是指单向时延（one-way-delay）,即从发端到收端的延时。算delay的框图以下：

仪器把参考音频经音频线送给手机，手机上行处理后经射频线再把码流送给仪器，仪器中造成一个loopback(上图中红色粗体处)，把这个码流经射频线送给手机。手机下行处理后把语音数据经音频线送给仪器，仪器把收到手机语音数据的时间和参考音频的发送时间作比较从而获得delay值。无论是MOS仍是delay都是测屡次（MOS测10次或者20次，delay测50次），而后算平均值做为最终得分。

 

测试EVS音频电学的这套仪器很是贵，没有几百万是搞不定的，后面还有每一年向仪器厂商缴的维护费用。大厂通常都会买上一套来调试各类音频电学指标。上文说过我如今的公司是本土新秀，老板不是很愿意花这么多钱在这上面。幸亏CMCC有仪器设备免费给相关厂商用，要提早预定，一般一星期批一次，一次两三个小时。可是通过两三个星期这样的运做后发现效率过低（手机校准（校准是为了找到最好的灵敏度值和gain值，相同的仪器和手机只须要作一次校准，若是有一个变化了就须要从新作校准）一次要花近两个小时，咱们的手机在实网下打EVS电话没什么问题，可是在仪器环境下测时好多case的EVS通话都创建不起来，须要各个领域的同事一块儿调查，也须要仪器侧技术人员的support，可是仪器侧的support力度很弱，进展太慢），老板决定向仪器厂商租设备来调试（租金也是至关昂贵的），即咱们到仪器厂商的实验室去调试。仪器厂商的实验室在北京，这样就有了我和CP同事的北京之行（咱们公司北京有office，测试同事就在北京）。在北京呆了一星期，一样遇到了很多问题，因为是在仪器厂商的实验室，遇到问题时他们支持的力度较大，大部分case都能测起来了，进而也就获得了相应的MOS分和delay值。良好网络下的MOS分不只没有一个达标的，并且有的离达标还很远，良好网络下的delay部分达标了。仪器厂商的技术人员安慰咱们说第一次过EVS认证都是这样的。在过EVS认证这件事上他们见多识广，咱们就当信觉得真，哈哈。

 

回到公司后咱们简单总结了一下，并制定了后面的策略：每星期由北京测试同事去仪器厂商实验室测试一到两天，一方面验证前面遇到的问题是否fix，修改后MOS分是否有提升，delay值是否有减少，另外一方面再继续测未测的case，即采用迭代的方式向前推动。先主攻良好网络下的MOS分。调查MOS分低（即音质差）主要是把各个处理过程后的语音数据dump出来，再辅以咱们本身开发的各类工具，最终都变成PCM数据用CoolEdit听，从而得出是哪一个处理过程把音质下降了（主要是噪声断续等），而后再在这个处理过程当中找到使音质下降的根本缘由。在前面文章（webRTC中音频相关的netEQ（一）：概述）中也说过咱们语音通讯中也用到了netEQ，只不过MCU模块在CP上，DSP模块在ADSP上。下行CP给ADSP发语音包和netEQ的控制命令，上行ADSP 给CP发语音包和netEQ的反馈信息（主要是上一帧的处理模式和时间戳等）。咱们主要作了四个工具。一是EVS decoder（基于3GPP EVS reference code），把EVS码流解码成PCM；二是解析下行dump出来的CP发给ADSP的语音码流和netEQ控制命令；三是解析上行ADSP发给CP的语音码流和netEQ反馈信息；四是netEQ DSP模块的simulator(模拟器)，把下行dump出来的CP发给ADSP的语音码流和控制命令做为输入，netEQ中DSP模块处理后的PCM做为输出，就能彻底复盘出问题的场景，从而找到根本缘由。在这些工具的辅助下发现了一些问题，也都一一解决了。通过几个星期的迭代，良好网络下的MOS分稳步提高，上下行都达到了3.9x，可是不达标（达标是4.0）。讨论下来在传输环节已经没有什么可作的了（依据是用CoolEdit听仪器中的结果音频，已经听不出任何噪声断续了），该负责VE的算法同事上场了。刚开始时算法同事也没什么招，后来听测试同事讲仪器厂商实验室有参考机，能够拿这个参考机测测，若是达标了看仪器上的结果音频是什么样的，好有参考。参考机测下来达标了，上行4.09，下行4.16。把结果音频发给算法同事，研究频谱等特性。算法同事尝试着修改VE里的参数，前三次以失败了结，让人好失望，甚至有点绝望，就差这零点零几分了！第四次尝试后总算达标了（上行4.10，下行4.20），好不容易啊！总结下来就是尽可能减小对语音信号的处理，保持原有信号的频谱等特性。改好后又测了良好网络下的其余case的MOS分，全都达标了。后面因为时间很少了，就开始兵分两路，一路负责恶劣网络下的MOS，另一路负责各类场景下的delay。恶劣网络主要分三个等级（1%丢包10ms jitter/2%丢包20ms jitter/3%丢包40ms jitter），相对OTT语音（好比微信语音，OTT语音常常会出现高于5%的丢包率）不是很恶劣，主要是由于LTE网络处理语音数据的QoS的级别较高，而OTT语音的QoS级别同其余数据业务（好比上网）是同样的，须要作好多补偿措施，具体有FEC、重传等，我在前面的文章（语音通讯中提升音质的方法）对这些措施作过具体介绍，有兴趣能够看一看。提升恶劣网络下EVS的音质主要是用好丢包补偿、平滑等算法。减小delay先是算出各个环节引入了多少delay，而后看是否能减小以及减小多少，主要是减小语音数据缓的时间。例以下行先有铃声数据进DMA buffer播放出来，语音数据到来后如放在未播放的铃声数据后就会引入delay，这就须要马上用语音数据去覆盖DMA buffer中未播放的铃声数据从而减小delay。无论是MOS仍是delay，要想达标，就在几个核心的点上，好比前面讲的改VE中的参数就是一个很重要的点，改了后就能提升0.2左右的MOS分。点找到了，达标也就不是很难了，每每是找到一个点并解决了须要很多时间，有时候花了不少时间也不必定能找到，须要很强的专业知识，仍是以修改VE参数的点为例，须要精通音频算法的专家。

 

过EVS音频电学认证前先后后花了四个月左右的时间，遇到了不少问题，参与人数也众多（咱们建了一个EVS认证的群，从最初的三四人到最终的近50人，不只有信令处理、媒体处理的，还有硬件的平台的以及空口的，都是遇到问题涉及到相关人员而拉进群的），能够算是一个不小的项目了。我做为过EVS认证的牵头者，不只要解决好媒体处理相关的问题，同时还要跟踪项目的状态制定计划等，部分承担了PM（项目经理）的角色，无论是技术上仍是项目管理上都收获颇多。