语音通讯从开始的只要有线通讯变成后来的有线通讯与无线通讯（移动通讯）的竞赛，当移动语音通讯价格下来后有线语音通讯显着处于逆势。现在移动语音通讯的竞赛对手是OTT（On The Top）语音，OTT语音是互联网厂商供给的服务，一般免费，如微信语音。现在语音通讯技能上就分成了两大阵营：传统通讯阵营和互联网阵营，相互竞赛，推进着语音通讯技能的开展。详细到编解码器上互联网阵营提出了包含语音和音乐的音频编解码器OPUS（OPUS是由非盈利的Xiph.org 基金会、Skype 和Mozilla 等一起主导开发的，全频段（8kHZ到48kHZ），支撑语音和音乐（语音用SILK， 音乐用CELT），已被IETF接收成为网络上的声响编解码规范（RFC6716）），绝大多数OTT语音的APP都支撑，有一统互联网阵营的趋势。移动通讯规范安排3GPP为了应对互联网阵营的竞赛，也提出了包含语音和音乐的音频编解码器EVS（Enhanced Voice Service）。我从前给我做的手机渠道上成功的加上了EVS，而且通过了中国移动的实网环境下的测验。下面就讲讲这个codec以及用好要做的作业。
3GPP在2014年9月将EVS编解码器规范化，由3GPP R12版别界说，首要适用于VoLTE， 但也一起适用于VoWiFi和固定网络电话VoIP。EVS编解码器由运营商、终端设备、基础设施和芯片供给商以及语音与音频编码方面的专家联合开发，其间包含爱立信、Fraunhofer集成电路研讨所、华为技能有限公司、诺基亚公司、日本电信电话公司（NTT）、日本NTT DOCOMO公司、法国电信（ORANGE）、日本松下公司、高通公司、三星电子公司、VoiceAge公司及中兴通讯股份有限公司等。它是3GPP迄今为止功能和质量最好的语音频编码器，它是全频段（8kHZ到48kHZ），能够在5.9kbps至128kbps的码率规模内作业，不只关于语音和音乐信号都能够供给十分高的音频质量，而且还具有很强的抗丢帧和抗延时颤动的才能，能够为用户带来全新的体会。
下图是3GPP EVS相关的SPEC，从TS26.441到TS26.451。
我已将要害的几个用红框标出，其间TS26.441是总览，TS26.442是用C言语写的定点完成（reference code），这也是后边用好EVS作业中的重中之重。TS26.444是测验序列，优化reference code过程中简直每天都要保存一个优化的版别，每天都要用测验序列跑一跑优化的版别，如发现不相同了，阐明优化的有问题，要退到上一个版别，并检查出哪一步优化出问题了。TS26.445是EVS算法的详细描绘，近700页，说实话看的头疼，假如不是做算法的，算法部分看个大约就能够了，可是对特性描绘相关的必定要细看。
EVS对语音信号和音乐信号选用不同的编码器。语音编码器是改进型代数码鼓励线性猜测（ACELP），还选用了合适不同语音类别的线性猜测形式。关于音乐信号编码，则选用频域（MDCT）编码办法， 并特别重视低推迟/低比特率情况下的频域编码功率，然后在语音处理器和音频处理器之间完成无缝牢靠的切换。下图是EVS编解码器的框图：
编码时先对输入的PCM信号做预处理，一起确定是语音信号仍是音频信号。如是语音信号就用语音编码器编码得到比特流，如是音频信号就用感知编码器进行编码得到比特流。解码时依据比特流中的信息确定是语音信号仍是音频信号，如是语音信号就用语音解码器解码得到PCM数据，然后做语音带宽扩展。如是音频信号就用感知解码器解码得到PCM数据，然后做频率带宽扩展。最终再做后处理作为EVS解码器的输出。
下面说说EVS的各个要害特性。
1，EVS支撑全频段（8kHZ–48kHZ），码率规模是5.9kbps至128kbps。每帧是20Ms时长。下图是音频带宽的散布：
窄带（Narrow Band， NB）规模是300HZ-3400HZ，对应的采样率是8kHZ，AMR-NB用的便是这种采样率。宽带（Wide Band， WB）规模是50HZ-7000HZ，对应的采样率是16kHZ，AMR-WB用的便是这种采样率。超宽带（Super Wide Band， SWB）规模是20HZ-14000HZ，对应的采样率是32kHZ。全带（Full Band， FB）规模是20HZ-2000HZ，对应的采样率是48kHZ。EVS支撑全频段，所以它支撑四种采样率：8kHZ、16kHZ、32kHZ和48kHZ。
下图是在各种采样率下支撑的码率：
从上图看出只要在WB下支撑全码率，其他采样率下只支撑部分码率。需求留意的是EVS向前兼容AMR-WB，所以它也支撑AMR-WB的一切码率。
2，EVS支撑DTX/VAD/CNG/SID，这同AMR-WB相同。在通话过程中一般有一半左右时刻说话，其他时刻处于倾听状况。在倾听状况时没必要发语音包给对方，所以就有了DTX（非接连传输）。要用VAD（静音检测）算法去判别是语音仍是静音，是语音包时就发语音包，是静音时就发静音包（SID包）。对方收到SID包后就去用CNG（舒适噪声生成）算法去生成舒适噪声。EVS中有两种CNG算法：依据线性猜测的CNG（linear prediction-domain based CNG）和依据频域的CNG（frequency-domain based CNG）。在SID包的发送机制上EVS跟AMR-WB不同，在AMR-WB中VAD检测到是静音时就发送一个SID包，然后40Ms后发送第二个SID包，随后每隔160Ms发送一个SID包，不过VAD一检测到是语音就马上发送语音包。EVS中SID包的发送机制可配，能够固定每隔一段时刻（几帧，规模是3–100）发送一个SID包，也能够依据SNR自习惯的发送SID包，发送周期规模是8—50帧。EVS SID包的payload巨细也与AMR-WB不同，AMR-WB的是40个字节（50*40=2000bps），EVS是48个字节（50*48=2400bps）。从上能够看出DTX有两个优点，一是能够节约带宽，添加容量，二是因为不编解码削减了运算量，然后下降功耗添加续航时长。
3，EVS也支撑PLC（丢包补偿），这也同AMR-WB相同。不过EVS把Jitter Buffer Module（JBM）也包含了进来，这在曾经的codec中是从来没有过的。我在运用中没有用到JBM，因为时刻比较紧，也就没有时刻去研讨。后边有时刻了定要好好研讨一下，JB可是语音通讯的难点之一一起也是语音质量的瓶颈之一呀。
EVS的算法时延依据采样率不同而不同。当采样率为WB/SWB/FB时总时延为32ms，包含一帧20ms的时延，编码侧输入重采样的0.9375ms时延以及8.75ms的前向时延，解码侧时域带宽扩展的2.3125ms时延。当采样率为NB时总时延减小为30.9375ms，相对WB/SWB/FB减小了1.0625ms， 这1.0625ms首要是在解码侧削减的。
EVS的语音质量（MOS值）相关于AMR-NB/AMR-WB有了显着的提高。下图是这几种codec的MOS值比较：
从上图看出，当采样率为NB时在各种码率下EVS-NB的MOS值比AMR-NB的MOS值明显提高；当采样率为WB时在各种码率下EVS-WB的MOS值相同比AMR-WB的MOS值明显提高；当采样率为SWB而且码率大于15kbps时EVS-SWB的MOS值接近了不编码的PCM的MOS值。可见EVS的语音质量是适当不错的。
用好EVS要做的作业在不同的渠道上会有所不同，我是用在手机渠道audio DSP上，用于语音通讯。下面就说说为了手机支撑EVS我做了哪些作业。
1，学习EVS相关的SPEC。要把前面我列的SPEC都看一遍，因为不是做算法，算法相关的能够看的粗，可是对特性描绘相关的必定要看的细，这联系到后边的运用。
2，在PC上生成encoder/decoder的应用程序。我是在Ubuntu上做的，把PCM文件作为encoder的输入，依据不同的装备生成相应的码流文件，再把码流文件作为decoder的输入，解码还原成PCM文件。假如解码后的PCM文件听下来跟原始PCM文件无异常，阐明算法完成是可信的（威望安排出来的算法完成都是可信的，假如有异常阐明应用程序没做好）。做应用程序是为了后边的优化，也便利了解外围完成，如怎样把编码后的值变成码流。编码后的值放在indices（最多有1953个indices）中， 每个indices有两个成员变量，一个是nb_bits，表明这个indices有多少位，另一个是value，表明这个indices的值。Indices有两种存储办法：G192（ITU-T G.192）和MIME（MulTIpurpose Internet Mail Extensions）。先看G192，每一帧的G192的存储格局见下图：
第一个Word是同步值，分good frame（值为0x6B21）和bad frame（值为0x6B20）两种，第二个Word是长度，后边是每个值（1用0x0081表明， 0用0x007F表明）。Indices里的value用二进制表明，位上的值为1就存为0x0081，为0 就存为0x007F。下图是一个比如，采样率为16000HZ， 码率为8000bps，因而一帧有160位（160 = 8000/50），保存成G192格局便是160个Word。下图中头是0x6B21， 表明good frame，length是0x00A0， 后边160个Word是内容。
再来看MIME格局。要把indices的value值pack成serial值，详细怎样pack，见pack_bit（）函数。MIME的格局是第一个Word是header（低4位表明码率index， 在用WB_IO时第5和6位要置1，EVS 时不需求），后边是比特流。仍是上面采样率为16000HZ码率为8000bps的比如，但存成MIME格局，一帧有160位，需求20byte（20 = 160/8），如下图：
上图中头16个字节是reference code自带的，第17个字节是header，0x2表明以EVS 编码，码率是8kbps（8kbps index为2），后边的20个字节表明pack后的payload。
在语音通讯中，要把indices的value值pack成serial值，然后作为payload发送给对方。对方收到后先unpack再解码得到PCM值。
3，原始reference code一般是不能直接运用的，需求优化。至于怎样优化，请看我前面写过的一篇文章（音频的编解码及其优化办法和经历），文章写的是比较通用的办法。我现在要在DSP上用，DSP的频率较低，只要三百多MHZ，不必汇编优化时搞不定的。我之前没用过DSP汇编，要在短时刻内优化的很好有很大难度。老板权衡后决议用DSP IP厂商供给的优化好的库，汇编方面它们更专业一点。
4，对reference code的应用程序改造，便利后边调试验证时当东西运用。原始reference code保存成文件时是以字节为单位的，而DSP是以Word（两个字节）为单位，所以要对reference code里的pack/unpack函数改造，以习惯DSP。
5，要想打电话时codec是EVS，Audio DSP 和CP上都要加相应的代码，先写各自的代码自调，然后联调。我自调时用AMR-WB的壳（因为EVS和AMR-WB的一帧都是20ms时长），即流程上用AMR-WB的，但codec从AMR-WB换成EVS。首要验证encoder、pack、unpack、decoder是否ok，其间encoder和pack是上行的，unpack和decoder是下行的。它们的先后联系如下图：
先调上行，把encode后的保存成G192格局，用decoder东西解码成PCM数据用CoolEdit听，跟自己说的话是相同的，阐明encoder是OK的。再调pack，把pack后的码流保存成MIME格局，相同用decoder东西解码成PCM数据用CoolEdit听，跟自己说的话是相同的，阐明pack是OK的。再调下行。因为CP还没有正确的EVS码流发给Audio DSP，就用loopback的办法来调试，详细是把pack后的码流作为unpack的输入，unpack后得到的保存成G192格局，用decoder东西解码成PCM数据用CoolEdit听，跟自己说的话是相同的，阐明unapck是OK的。最终调decoder，把decoder后的PCM数据用CoolEdit听，跟自己说的话是相同的，阐明decoder是OK的。这样自调就完毕了。
6，与CP联调。因为前面自调时各要害模块都是调好的，联调起来相对比较顺利，没几天就调好了。这样打电话时就能享用EVS带来的高音质了。
