又被“过运营商语音认证”虐了一回！虐的伤痕累累、疲惫不堪！过程是痛苦的，但结果是美好的，收获也是挺多的！既然用了“又”，那以前肯定被虐过。是的，没错。那是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(上图中红 {MOD}粗体处)，把这个码流经射频线送给手机。手机下行处理后把语音数据经音频线送给仪器，仪器把收到手机语音数据的时间和参考音频的发送时间做比较从而得到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（项目经理）的角 {MOD}，不管是技术上还是项目管理上都收获颇多。