语音通讯中终端上的时延(latency)及减少方法

时延是语音通讯中的一个重要指标，当端到端(end2end)的时延（即one-way-delay,单向时延）低于150Ms时人感受不到，当端到端的时延超过150Ms且小于450Ms时人能感觉到但能忍受不影响通话交流，当端到端的时延大于1000Ms时严重影响通话交流，用户体验不好。同时时延也是语音方案过认证的必选项，超过了规定值这个方案是过不了认证的。今天咱们就讲讲时延是怎么产生的以及怎么样在通讯终端上减少时延。

 

1，时延产生

下图是语音从采集到播放的传输过程。

 

从上图看出，传输过程包括三部分，一是从发送端采集到语音数据处理后发送到网络设备，二是网络设备之间传送，三是从网络设备发送给接收端并播放出来。每一个过程都会产生时延，整体能够分为三类。一是通讯终端上引入的时延，这时本文要讲的重点，后面具体讲。二是通讯终端和网络设备之间的时延，包括采集终端到网络设备的延时和网络设备到播放设备的延时。三是网络设备之间的时延。二和三属于网络设备引入的延时，本文不讨论。

 

如今咱们具体看通讯终端上引入的时延，它在发送端（或者叫上行/TX）和接收端（或者叫下行/RX）都有。在发送端主要包括声音的采集引入的延时、前处理算法引入的延时和编码算法引入的时延。声音采集时一般5Ms或者10Ms从采集DMA中取一次语音数据，可是编码时多数codec要求的一帧是20Ms（好比AMR-WB），这二者之间不匹配，就要求采集到的数据放在buffer里缓一段时间，等到帧长时再取出来去编码，这就引入了时延。以一帧20Ms为例，就会引入20Ms的延时。前处理算法主要有AEC、ANS、AGC，这些算法都会引入延时，这跟滤波器的阶数有关，阶数越多，延时越大。编码算法同前处理算法同样也引入了延时。在接收端主要包括端网络延时、解码算法延时、后处理算法延时和播放延时。端网络延时主要出如今解码以前的jitter buffer内，若是有抗丢包处理（例如FEC）延时还会增长（有FEC增长延时的缘由是要等接收到的包到指定个数才能作FEC解码还原出原始包，用FEC抗丢包的原理我在前面的文章（语音通讯中提升音质的方法）中写过）。解码和后处理算法和发送端的编码前处理相似有延时。播放前为了保持播放的流畅性会在语音数据进播放DMA前加一级buffer，这也引入了延时。

 

2，时延测量

时延是过认证的必选项。对于语音通讯解决方案来讲，先得让时延低于认证指定的值，而后再看有没有减少的可能。如能够将时延作到更小，则是该方案的亮点。要测量时延就得在实验室搭建一个理想的端到端的语音通讯系统（理想是指网络几乎不引入时延），同时两端均采用该语音方案，这样就能够用仪器测出端到端的延时了。测时延时，仪器上显示的时延是一个平均值，等通话时长达到必定值后就会稳定下来。拿它跟认证指定的值比较，若是大于指定值，认证是过不了的，先要减少时延让它低于指定值。若是低于指定值，则说明该方案有一个好的起点，能够继续减少让其成为亮点。

 

用仪器测出来的单向时延大致上应该是终端上各个模块引入的时延之和。要减少时延首先得搞清楚是哪一个模块引入的时延较大。有些模块引入的时延是已知固定的，且不能减小，好比信号处理算法模块。有些模块引入的时延是未知的，咱们就须要去测量这个模块引入的时延具体是多少。作这些前须要对该语音通讯方案的软件架构熟悉，知道方案中有几个（除了信号处理算法模块外）引入时延的点。这种时延一般是对buffer的存取引入的时间差，该怎么测出时延值呢？我通常用以下的方法：当把语音数据放进buffer时记下当时的时间t1，保存在这段数据开始的地方（虽然破坏了语音数据，不过不要紧，咱们只是用来测延时，是一种手段，不关心语音质量），当从buffer中取出这段语音数据时，再记录下时间t2，将t2减去保存在数据中的t1就获得本次存取引入的延时。统计很是屡次（我一般用一万次）再算平均值，就能够获得这个点引入的时延了。下面举例说明。有一块能够存5帧（每帧20Ms）的buffer，某一帧语音数据放在第三帧处。放时的时间是158120毫秒，将这个值放在放这段数据开始的地方。将这段数据从buffer里取出来时的时间是158180秒，能够算出本次延时是60Ms（158180-158120=60），统计10000次，算出延时总和，再除以10000，获得延时平均值是58Ms。因此这个点引入的时延是58Ms。

 

3，时延的减少方法

知道了各个点引入的时延大小，下面就要看怎么减少时延了。这里的减少是指能减少的，有些是不能减少的，好比codec引入的时延。我用过的方法主要有如下两种。

1）用减少缓冲深度来减少时延

这种方法说白了就是让语音数据在buffer里呆的时间短些，好比之前在buffer里有了3帧（假设每帧20Ms）语音数据才会从buffer中取出给下一模块，这样平均就会引入60Ms的时延。若是将3帧改成2 帧，则平均引入的时延就降为40Ms，这样就减小了20Ms的时延。不过用这种方法是有条件的，要确保语音质量不降低。改了后要用仪器测，若是长时测试下语音质量不降低就说明这个改后的值是能够接受的。通过试验后找到一个能够接受的缓冲深度的最小的值，就把这个值用在方案中。

 

2）用加速信号处理算法来减小时延

音频信号处理中有个算法叫加速，它是对PCM信号进行处理，在不丢失语音信息的前提下把时长减少，它的原理是WSOLA。好比原PCM数据时长是5秒，通过加速处理后变成了4秒，人听上去信息没丢失，可是语速变快了。若是在buffer中待播放的PCM数据较长，确定延时较大，能够经过这种加速算法把要播放的数据处理一下，变成短时长的PCM数据，这样就能够减少延时了。我第一次作voice engine的时候，除了减少buffer缓冲深度没有其余好的方法来减少延时。后来作了语音加速播放的功能（具体见我前面的文章：音频处理之语音加速播放），以为能够用这个算法来减少延时。但是当时事情很是多，再加上要作到延时减少了但同时也要让听者感受不到在加速播放还有不少细节工做要作，也就没作成。随着webRTC风靡音视频开发圈，我也开始关注。了解到其中的netEQ就有用加速算法来减少延时的功能，看来英雄所见略同啊。哈哈。同时我也感受到要多作东西，见多才能识广呀，说不定结合之前作过的东西就能获得解决问题的好的思路呢。固然加速减小延时功能只是netEQ的一部分。netEQ主要是解决网络抖动延时丢包等问题来提升语音质量的，能够说说目前公开的处理此类问题的最佳方案了。从下篇开始，我将花几篇文章来详细的讲讲netEQ。netEQ是webRTC中音频相关的两大核心技术之一（另外一个是先后处理，有AEC/ANS/AGC等），很值得研究。