多媒体会议系统中的延迟

多媒体会议系统中的延迟

端 对端的音频延迟在任何语音通信系统中都是极其重要的特性。用户感觉交谈和会议中的自然性与交互性都强烈依赖于系统的音频延迟。如果系统延迟太长使得会谈各方不方便或者很困难交互，这样的系统当然不会被公众所使用。这就使得延迟成为语音通信系统设计中所要考虑的最重要的因素之一。

对于不同环境，不同的人感觉到延迟变化很大。有些人看来比别人对延迟更敏感。这可能与会谈方式或个性有关系。比如，有的人习惯打断别人说话或者发出表示“同意”的声音，如”uhhuh”、”yes”，而这可能与远端的说话人不同步。尤其要重视笑语的延迟问题，因为延迟的笑声看起来像是被强迫发出的。

视 频会议系统的使用表明接受增加了音频延迟以换取为视频作准备的愿望。视频给会议或会话增加了一个新的方面。然而，会议中可以接受（尽管很烦）的延迟在一对一的交谈中会产生非常不同的效果。一般要求将会议组织得更有条理，只有一个发言者或许多听众，并且很少会出现打断发言者的情况。

H.320视频电话的新用户经常抱怨语音是“半双工”的，但实际上它使用的是全双工。这些用户以为不能打断远端用户是由于半双工音频，但实际上是因为延迟的问题。

这里也可能有风俗习惯的因素。可能因为日本有在一对一会谈中经常使用“Hai”应答的习惯，所以日本的视频会议系统的用户经常不使用唇音同步功能，这样音频不会在和视频同步时被更大地延迟。

在有些情况下视频的出现能直接补偿音频延迟的问题。有些用户学习在视频呼叫中点头或微笑以及其他反应以取代用声音在电话中应答。

在语音通信系统中可以忍受的总延迟变化依赖于环境。大多数观察家认为50~100ms的单向延迟一般不被人注意。ITU-T G.114认为低于150ms的单向延迟对于“大多数应用是可接受的”，但同时指出，一些高度交互的声音和数据应用在延迟低于150ms时也可能会使质量降低。因此，如果没有明显的服务和应用效益，使延迟远低于150ms也是不可取的。

对比来看，同步地球卫星电话电路从轨道上的卫星传输回的延迟大约250ms，这使许多用户感到烦恼。这就是为什么许多跨越大陆电话采用海底电缆的原因之一。

对人的因素在电信系统中延迟效果的研究中，研究者Kitawaki和Itoh（1991年)发现，在一个会谈效率度量中（如正确的数字和姓名），250ms的单向延迟使零延迟损失效率 20~30%。他们得出结论认为，“通信系统中大约500ms（单向250ms）的长途传输延迟将给相当多的参与者造成很大困难”。

（一）音频延迟来源

多媒体会议系统中的音频延迟来源于以下七个方面：

·             算法延迟（在编码前积累音频样本所花的时间）

·             处理延迟（执行编码和解码算法所花的时间）

·             复用延迟（已编码在传输开始前所必须等待的时间）

·             传输延迟（传送代表音频的比特所花的时间）

·             调制延迟（调制和解调信号所花时间）

·             传播延迟（信号到达目的地所花的时间）

·             缓冲延迟（信号存储所花时间，包括信号到达时为消除抖动所花的时间）

在这些延迟中，算法延迟、处理延迟和缓冲延迟中的一部分被认为是归因于所使用的音频编解码器，而独立于其他系统元素。

除此之外，在现实的实现中，有时中断响应时间会增加额外的延迟，尽管同步实现将这个延迟减到最低。不像其他的延迟来源，这纯粹与实现有关，此处不做更深入的谈论。

（二）音频延迟分析

1. 算法延迟

算法延迟是编码开始以前取得音频样本所需时间。基于帧的编解码器如G.723.1和G.729，这个延迟时间为一个帧的持续时间加上编码算法的预处理时间。假定编解码时间为零（一个无限快的处理器），对于编解码器来说这是所需的最小延迟。

对G.723.1来说，计算延迟为（30+7.5）ms，共计37.5ms。对于G.729，计算延迟为（10+5）ms，共计15ms 。

2. 处理延迟

处理延迟是在CPU或DSP芯片上执行编码和解码算法所需时间。它等于编解码器算法的复杂性（用MIPS描述），除以CPU或DSP的执行速度（用MIPS表示），乘上音帧的持续时间：

    处理延迟 = 复杂性/DSP速度*帧大小

原则上，编解码器在编码和解码之间能很好地划分DSP周期或者能顺序执行编码和解码。这种选择简单地在逝去的处理时间和排列时间之间交换，而不影响总延迟。

实时实现通常使用能跟上实时处理的最慢的DSP（这是最便宜的能满足要求的DSP芯片），所以处理时间通常和编解码帧大小一致。对于G.723.1是30ms；对于G.729为10ms。

在普通CPU上的软件可以实现在短时间内将CPU最大的处理能力用于音频处理，降低音频处理延迟。然而，PC操作系统中显著的中断延迟可能抵消这些好处。

3. 复用延迟

当一个数据单元，如编码音频帧，准备传输和它能够通过使用的复用，实际上在线路上传输两者之间的时间差即为复用延迟。如果一些其他的数据已经开始传输，在新的数据单元能够开始传输之前必须等待一段时间。这可能与TDM复用的帧长度有关或与包复用中最大包长有关。由于这个延迟经常是变化的，实际系统必须缓冲最大可能延迟，从而允许接收方能平滑播放。

理想的复用，可以设想为是在一个高比特率的信道上模拟许多个低恒定速率的信道。事实上，这样的复用对于产生恒定比特率的媒体源很理想。然而，实际上的媒体源不适合于这个模式，因为他们一般都是突发产生数据。

音频编解码器如10ms帧的G.729就是这样的一个例子。在帧生成的10ms期间，音频编解码器不产生任何输出。在帧间隔结束时，代表10ms帧的整个比特流立即就成为可用的。在下一个10ms帧时间内传送这些比特流（产生一个恒定比特流）只会增加额处的10ms端对端延迟。当一帧比特送完、下一个帧准备好之前所剩下的时间，能够用来传送别的数据类型。

H.223复用接近这种模型。它的音频复用延迟为 16~24比特传输时间，包括完成传输当前字节所需时间，然后发送HDLC标志和1字节头以开始传输音频帧。在普通的H.324速率上这将大约花1ms。

4. 传输延迟

传输延迟指的是发送代表最小的可解码音频信号单元的比特所需的时间。在只有音频的电话系统中，传送延迟与帧一样大，因为传输信道除了音频信息外不传送其他任何信息。在多媒体通信系统中，传送延迟要小一些，因为传输媒体的运行速率要高于只用于音频的速率。

传输延迟为音频帧的长度除以当前使用的比特率。使用5.3 kbps音频率的G.723.1（包括CRC共21字节帧长）运行比特率为24kbps时，传输延迟为7ms。对于G.729（11字节帧长，包括CRC），传输延迟为3.67ms。

5. 调制延迟

调制延迟是调制和解调数字信号于物理传输媒体所需的时间。对于V.34调制解调器来说，因为它相当复杂，估计其调制延迟大约为35ms。

6. 传播延迟

传播延迟是信号通过物理传输介质到达目的地所花的时间。它变化很大，依赖于网络的拓扑结构，传输介质的物理特性以及覆盖的物理距离。对于PSTN来说，传播延迟的变化范围从接近0（本地呼叫）到超过250ms（通过地球同步卫星电路路由的呼叫）。

当分析多媒体通信系统时，传播延迟有时被认为包括从任何来源获得的出现在网络中的所有延迟，它包括中继器和放大器、卫星发射器、数据包路由选择和网络阻塞等。

7. 缓冲延迟

缓冲延迟是由于实时数据的存储和考虑到音频到达时间的不可预测（抖动）、平滑异步处理以及匹配不同速率数据的传输所产生的。

平滑的音频播放要求有足够缓冲来接收数据以避免由于帧到达时间延迟所引起的音频间断。H.324标准允许最多 10ms的传输音频延迟，这能够用来在复用流中等待一个自然的间断点、增加线路效率或者简单地考虑传输实现中的中断延迟。同步多媒体通信系统如H.320只有很少的抖动，而包交换系统H.323有更多的抖动。

尤其是当帧到达时间不可预测时，缓冲也是DSP所需的。当一个音频帧准备进行处理时，DSP可能已忙于处理相反方向的音频，或者按计划很快会忙于进行别的处理。音频可能在处理前不得不等待直到整个帧时间。像处理延迟一样，这种队列延迟可能通过使用更快的DSP来减少，但正常的花费考虑意味着使用保持实时的最慢的DSP。

因此对于H.324延迟估计，我们将为传送方抖动指定10ms，加上一帧时间用于DSP安排；对于G.723.1来说结果是10+30 = 40ms的缓冲延迟；对于G.729来说结果是10 +10 = 20ms的缓冲延迟。

8. 音频延迟估计

把这些条目加在一起，我们能够得出H.324的音频延迟估计（表 16-05-4 ）。

表 16-05-4 H.324音频延迟估计

	G.723.1	G.729	说明
算法延迟	37.5ms	15ms
处理延迟	30ms	10ms
复用延迟	1ms	1ms
传输延迟	7ms	3.67ms
调制延迟	35ms	35ms
缓冲延迟	40ms	20ms	10ms抖动+1帧
合计（单向）	150.5ms	84.67ms	不包括传播延迟

当评价多媒体终端选择时，传播延迟通常不是一个明确的因素，因为它处于终端设计和实现控制之外。然而，当评估通信系统的整体性能时，实际网络中的传播延迟、视频延迟、预处理以及后处理延迟都必须一起加以考虑。