浅谈传统语音通讯和APP语音通讯音频软件开发之不一样点

本人在传统的语音通讯公司作过手机和IP电话上的语音软件开发，也在移动互联网公司作过APP上的语音软件开发。如今带实时语音通讯功能的APP有好多，主流的有微信语音、QQ电话、钉钉等，固然也包括我开发过的那款APP（那款APP在实时通讯APP排名中一直靠前）。既然都作语音软件开发，那确定有不少共同的地方，好比须要相同的语音专业知识，都有语音前处理、编解码、传输等。经过本身的观察，也有一些不一样的地方。咱们今天主要聊聊这些不一样点。

 

1，在传统语音通讯公司都是在具体硬件上开发音频软件。有了硬件就要有相应的驱动，在Linux/Android上就是ALSA相关的驱动软件开发。对于前处理、编解码、传输等模块，既能够在底层作也能够在偏上面的层次作，这取决于软件架构。我曾经在Linux平台上硬件同样软件需求同样的状况下因为软件架构不同开发过两套语音方案。一套方案是驱动在kernel space作，前处理、编解码、传输等在user space作。另外一套方案是驱动和前处理、编解码、传输等所有在kernel space作。之因此要作两套方案是由于第一套方案的性能不够好，尤为表如今one way delay上。

 

在移动互联网公司作APP上的语音软件都是在上层作开发。驱动等对开发人员是黑盒子，开发人员要作的有前处理、编解码、传输等，用好系统提供的API就能够了。以Android为例，对作APP来讲用好media framework里提供的audio相关的（AudioRecord/AudioTrack等）API 就能够了。

 

2，上面说过在传统语音通讯公司里都是在具体硬件上开发软件，一些音频相关的参数就只有一套，在这个硬件上调好了就能够了。而在APP上作语音软件开发，不针对具体的硬件。可是一些音频参数要依赖于硬件，不一样的硬件上参数不同，一个手机上调的效果很好的参数到另外一个是手机上可能效果就很糟糕，因此在APP上作音频软件开发一个很重要的工做就是硬件适配。在不一样的机型上用不一样的参数，最起码也要把主流的机型适配好，一些用户量大的APP要适配上百款甚至几百款机型。以回声消除为例，它的一个很重要的参数就是从speaker（远端）出来到mic（近端）进去的时延，不一样的机型时延不同，这主要由于两点：1）硬件不同，2）作APP都是在上层作，它要从底层拿到远端和近端的PCM数据，不一样的手机底层实现不同，时延也会不同。开发时就要把尽量多的机型上的时延获得保存起来，用户使用时根据不一样的机型给出不一样的时延值。

 

3，在传统通讯公司开发语音软件，若是作有线产品，codec通常选用ITU-T的G系列（G711/G722/G726/G729等），若是作无线产品，codec通常选用3GPP的AMR系列（AMR-NB/AMR-WB等）。在APP上作语音软件开发，codec更多的会选用互联网阵营里提出来的iLBC/OPUS等。如今作语音通讯，基本上造成了两大阵营，即以ITU-T/3GPP为表明的传统阵营和互联网阵营，在codec上都有各自的演进策略。传统阵营会演进到EVS（支持语音和音乐，最高48K采样），互联网阵营会演进到OPUS（支持语音和音乐，最高96K采样）。中国移动已要求移动终端17年末可选支持EVS，18年中必须支持EVS，传统阵营要求这么快演进也是被形势所逼。前几天微信语音功能进行了更新，能够像系统电话那样来接听微信语音电话，又要革电话的命了，之前革了短信的命。我的以为互联网公司在语音codec上选择iLBC/OPUS还有一个缘由是由于他们的语音方案多基于开源的来作，好比webRTC，而这些codec是开源方案里自然支持的，互联网又要求快，他们必然会选择这些已经调试适配好的codec。

 

4，在传统通讯公司开发语音软件，必定要严格遵照各类协议（主要有3GPP/ITU-T/RFC的），不能有本身私有的协议，由于要过互通性测试。运营商在采购通讯设备时通常会采购多家设备商的（采购多家设备商的设备有多方面缘由，其中之一就是不想让一家设备商一家独大造成垄断从而受制于他），通讯终端更是多种多样，你们必须遵照相同的协议才能互通，因此必定要严格遵照各类协议。

 

在移动互联网公司开发APP上的语音软件，客户端（前台）是本身开发维护，服务器（后台）也是本身开发维护，即全部都是本身开发维护，不存在跟其余厂家的产品互通。这样就会用不少私有协议。我开发过的那款APP就用了好多私有协议，有的是本身提出来的，有的是对已有公开协议的改造。这些协议若是有文档还好，若是没文档在看代码时就会特别累。

 

5，在语音通讯过程当中，通常有一半左右的时间在讲话，剩下的时间在听。在传统通讯公司开发语音软件，为了节省带宽和下降功耗，会对采集到的声音作能量检测（叫静音检测VAD），当声音能量低于设定的门限值时就不发语音包给对法，取而代之的是发SID（Silence Insertion Descriptor）包给对方，一般是每隔一段时间发一个这样的SID包，好比AMR-WB中的160ms，并且这种包的payload size很小。这相对于每隔20ms发一个的语音包来讲大大的节省了带宽。接收端收到SID后就会作CNG，产生温馨噪声。因为不须要再作编解码，这也必定程度上下降了功耗。在移动互联网公司开发APP上的语音软件，一般不考虑这些，全部采集到的语音数据都编码用RTP打包发给对方。我开发过的以及微信都是这么作的。

 

6，传统语音通讯都是有QoS保障的，语音包的优先级是高于通常数据包的，会有一些措施来作丢包补偿，可是措施不会特别多，常见的有PLC等。APP上的语音又叫OTT（Over The Top，是指互联网公司越过运营商发展基于开放互联网的各类音视频及数据服务业务）语音，没有QoS保障，为了保证语音质量，一般会采起多种补偿方法，常见的有重传、FEC等。在弱网状况下这些方法虽然会提升音质，可是要增长流量。若是几种补偿方法同时用，可能会成倍或者几倍的增长流量。

 

7，传统通讯网络一般会划分为终端、接入网、核心网等不一样的网元，以下图：

                                          

做为语音通讯，终端会把采集到的语音编码后打包通过attached的接入网设备核心网设备到对方attached的接入网设备再到对方终端播放出来。通常接入网设备和核心网设备只会透传语音数据不会修改语音数据。

 

在APP上开发语音软件，通常采用client-server机制，以下图。

                                                    

Client A 与Client B进行语音通讯，A把语音数据发给B。A先把语音数据发给server的PORT A，server会把PORT A的数据路由到PORT B，再由PORT B把语音数据发给Client B。为了保证语音质量，通常会作两次补偿，先在server的PORT A上根据丢包率等作一次补偿，尽量复原出Client A发出的语音数据。再在Client B上作补偿，尽量复原出PORT B发出的语音数据。也就是说server会对客户端发过来的语音数据作修改的，而不是透传的。

 

8，在传统通讯公司作语音软件开发，必定要过运营商的入网认证，包括各类场景下的语音质量（MOS值）、one-way-delay、round-trip-delay等指标。这些指标必定要过，否则拿不到入网证，拿不到入网证也就不能卖产品了。这些指标一般都是拿仪器测是否经过，要想过运营商的指标，公司通常都会有音频实验室，里面放着运营商指定的各类仪器，来模拟指定的各类场景。本身公司实验室里指标测过了才有信心拿到运营商指定的实验室去测。过认证是一个很痛苦的过程，由于这些都是系统性的问题，解决起来都是不容易的，有可能某个指标花了很长时间解决都不达标。话说回来，解决这些系统性问题的过程也是本身能力提升的过程，整个指标一遍作下来，能力会有一个大的提升。

 

在移动互联网公司作APP上的语音软件开发，不会有入网认证，任什么时候候均可以发布产品。通常公司也不会建音频实验室，由于建一个音频实验室花费较大（像腾X这样的巨头是有的，它作的很专业，它的两款APP产品这么大的用户量要求它必须作的很专业，作的不专业音质很差会把产品口碑作差的，并且这点花费对它来讲不算什么）。各类场景下的语音质量等指标没有一个确切的数据。用户下载了APP用后以为语音质量好就会继续用，以为语音质量很差的话就会卸掉不会再用了。

 

以上就是我基于作过的公司观察到的一些不一样点，有可能有遗漏，后面想到了再补上。也有可能其余移动互联网公司作法有不一样的地方，欢迎你们补充。