时延是语音通讯中的一个重要目标，当端到端(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等），很值得研讨。
