如何去解决以太网音频时延的问题？

　　随着网络技术的快速发展，VoIP技术得到了广泛的应用。特别是在局域网环境下，VoIP凭借其应用便捷，价格低廉的优点，已经成为了人们即时交流的主要方式之一。从实际应用效果来看，时延成为影响VoIP话音质量的关键因素。ITU-TG.114规定，对于高质量语音可接受的时延是300 ms。一般来说，如果时延在300～400 ms，通话的交互性比较差，但还可以接受。时延大于400 ms时，则交互通信非常困难，所以如何确保音频实时传输已经成为VoIP技术中首要解决的问题之一。
　　本文首先介绍了VoIP原理和基本实现流程，然后对以太网环境下实时音频传输进行了实验研究，分析了缓冲区设置和音频API调用对音频时延的影响，并根据分析结果，提出了解决以太网音频时延的对策。
　　1、VoIP原理及其基于PC平台的实现流程
　　VoIP的基本原理是：发送端通过语音的压缩算法对采集到的原始语音数据进行压缩处理，然后把这些压缩后的语音数据按TCP/IP标准进行打包，经过IP网络把数据包发送至接收端；接收端将分组话音重组，经过解压处理后，恢复成原来的语音信号，从而达到由网络传送语音的目的。
　　图1为基于PC平台的VoIP实现流程。如图所示，基于PC平台的VoIP应用的基本实现包括接收模块、发送模块和网络传输三部分构成。其中，发送模块主要由音频采集、音频编码、分组话音封装等部分组成。接收模块的实现过程一般由发送模块的逆过程构成，主要包括分组话音的接收，音频解码及音频播放等部分组成。
　　
　　图1　基于PC平台的VoIP实现流程
　　下面分别介绍各部分功能以及常规的实现方式。
　　音频采集和播放模块主要对音频信号进行采集和回放操作，完成模拟语音和数字语音之间的转换。它主要通过音频API函数来实现其功能。在Windows操作系统中，常见的音频API函数有：WaveX、DirectSound和ASIO等。
　　音频编码与解码模块主要完成对语音数据的压缩与解压功能。在发送端由于采集到的原始语音数据量比较大，需要对原始语音数据以特定的音频格式进行压缩编码。同理，在接收端需要对接收到的语音数据进行解压还原。在Windows操作系统中，ACM（Audio Compression Manager，音频压缩管理器）管理着系统中的所有音频编码译码器（CODEC），负责对语音数据进行压缩与解压缩。CODEC是一小段用于压缩（Compress）及解压缩（Decompress）数据流的代码。CODEC可以是由操作系统本身附带的CODEC，也可由系统中所安装的应用程序安装其他的CODEC。
　　分组话音封装和分组话音接收模块主要是为压缩后的语音数据加上相应的报头，使其成为一个语音包，然后送给传输模块。TCP/IP协议体系中有两个不同的传输层协议，分别是面向连接的传输控制协议TCP和无连接的用户数据报协议UDP。这两种协议的不同之处在于UDP提供无连接的服务，在传输数据之前不需要先建立连接，远程主机接收到UDP数据后，不需要给出任何确认；而TCP则提供面向连接的服务，在传送数据之前必须先建立连接，数据传送结束后要释放连接。对于音频应用来说，一般使用UDP协议。这是因为虽然UDP协议不提供错误重传的功能，但是它可以保证音频数据的实时性。
　　网络传输模块就是将封装好的IP语音数据包从发送端发往接收端。在Windows操作系统中，主要通过Winsock函数来完成。
　　2、缓冲区大小与时延的关系
　　缓冲区大小与时延有着密切的关系。一般来说，缓冲区大时，时延较大，但是可以有效地进行失序重组等操作，话音质量较好；缓冲区较小时，时延较小，但由于缓冲并没有很好地消除时延抖动等因素，导致话音质量较差。所以要将缓冲设为合适的大小，使得时延较小，同时又保持着较好的语音质量。
　　实验程序是我们前期编写的PCtoPC的VoIP程序，是由VC++编写的，使用低阶的音频API-WaveX函数来实现音频的采集和回放；使用ACM来进行语音的压缩和解压缩；使用Winsock来进行网络通信。实验程序实现了网络语音传输的基本功能，程序中采集和回放缓冲区大小相同，个数均为2，采用乒乓制。
　　我们在以太网环境下对缓冲区大小与端到端时延的关系进行了测量。其中端到端时延测量的思路是：运行程序，从麦克风输入一个激励，从耳机端得到一个输出，如果能获得两者时间之差即为端到端时延。可以在本机拨打本机运行测试，这样不需要考虑同步的问题，而且由于测试环境基于100Mbit/s以太网链路，链路传输时延为微秒级，可以忽略不计，所以本机环回测试得出的结果基本可以表征端到端时延。测量的具体方法是通过示波器，产生一个适当的信号，模拟语音输入，然后观察输出，得到两者时延。测试程序中使用的编解码算法是GSM610，参数为 11.025kHz的采样频率，8位单声道方式，音频API为 WaveX的情况下进行了测量，实验结果如表1所示。
　　表1　缓冲区大小与时延关系
　　缓冲区大小（byte） 512 768 1024 1536 2048 4096
　　语音的时长（ms） 46 70 93 140 196 392
　　测得的端到端时延（ms） 约350 约400 约500 约600 约700 约800
　　在上述测试环境中，每个样本点量化为一个字节，采样频率为11.025kHz，每秒钟产生的原始语音数据的大小为11025字节。语音的时长为缓冲区大小除以11025，所以语音时长也应是缓冲区时延。
　　在实验中，我们发现，当缓冲区为512字节时，虽然能够获得较小的缓冲时延，但此时话音的停顿感非常明显，音质很差。而如果将缓冲区设置为768字节，那么音质可以得到明显改善，但是并未增加多少打包时延，因此在后期实验中我们将缓冲区设置为768字节。
　　从表1中可以看出，当缓冲区增大时，时延明显增大。但当缓冲区相当小（512字节）时，时延并没有显著降低，稳定在350ms左右，而相应的语音时长只有53ms。显然，除了缓冲区打包和传输之外，VoIP传输通路中的其他因素也引入了较大的时延。本文的第三部分将对端到端时延的具体构成作详细分析。
　　3、以太网环境下时延的构成
　　VoIP中的时延存在于整个IP电话的各个环节，如图2所标示，可以大致分为4个部分：（1）音频采集和播放时延。为音频API引起。（2）缓冲时延。缓冲时延是发送端缓冲区中排除等待时间和接收端拆包时引入的时延。如本文第2节中实验所示，缓冲时延与缓冲区大小有关。（3）语音编/解码时延。由语音编码算法引起，根据不同的算法，其值也不同，但差距不大，经验值在5～40ms之间。（4）网络传输时延。网络传输时延是数据通过网络传输到达目的地所需的时间。
　　
　　图2　VoIP时延分布
　　由于以太网带宽较大距离较近，网络时延一般情况下小于1 ms，可以忽略不计，所以在局域网环境下的VoIP的时延主要是由语音编/解码时延、打包/缓冲时延和音频采集和播放时延构成的。
　　为了进一步确定在以太网条件下VoIP各部分时延的分布情况，我们通过使用QueryPerformanceCounter函数在实验程序中设置时戳进行了具体的实验分析。QueryPerformanceCounter函数可以精确的计时。我们在本机进行环回通话测试，编解码方式为 GSM610，参数为11.025kHz的采样频率，8位单声道方式，缓冲区为768字节，音频API为WaveX的情况下，对程序的音频采集部分，压缩部分，解压部分，音频回放部分进行了时延测量。实验中原始音频数据为一个缓冲区大小。实验结果如表2所示：
　　表2　采用WaveX的程序各部分时延构成
　　音频采集时延 压缩时延 解压时延 音频回放时延
　　约180ms 约5ms 约5ms 约200ms
　　我们通过将各部分时延相加，可得到端到端时延约为390ms。这与本文第2节中的实验结果基本一致，说明我们的实验结果是可信的。根据实验结果，我们可以看出时延的主要组成来自于音频采集时延和音频回放时延，分别除去缓冲区时延（语音时长）93ms后，还有约200ms，这部分应为低阶音频 API-WaveX所导致的。
　　4、解决以太网时延对策分析
　　根据第3节的实验结果，为了缩小时延，我们必须考虑使用性能的更好的音频API。
　　我们对程序进行了修改，使用DirectSound替代WaveX进行音频的采集和播放。WaveX没有硬件加速功能，CPU利用率较高，延时较大。DirectSound是DirectX API的音频组件之一，它可以提供快速的混音，硬件加速功能，并且可以直接访问相关设备。DirectSound允许进行波型声音的捕获，重放，也可以通过控制硬件和相应的驱动来获得更多的服务。DirectSound与WaveX相比技术较新，功能强大，能够支持混音，硬件加速操作，采集和播放时产生的延时较小。
　　下面简要介绍一下实现DirectSound的步骤：DirectSound采集声音流程如图3所示，其中 DirectSoundCaptureEnumerate函数用来枚举系统中所有录音设备，DirectSoundCaptureCreat函数创建设备对象，然后通过CreatCaptureBuffer函数来创建一个录音的缓存对象，Se tNotificationPositon函数用于设置通知位，以便定期的从录音缓存中拷贝数据。DirectSound播放声音流程如图4所示，其中DirectSoundCapture、 DirectSoundCreat和CreatSoundBuffer函数也是做一些初始化的工作。Lock函数用于锁住缓存的位置。然后通过 WriteBuffer函数将音频数据写入缓冲区，写完后再通过UnLock函数解锁。
　　
　　图3　采集声音流程　图4　播放声音流程
　　我们在与第3节相同的实验环境下，对采用DirectSound的程序进行了时延测量，通过示波器测得的端到端时延约为250ms左右，时戳测量的结果如表3所示。
　　表3　采用DirectSound的程序各部分时延构成
　　音频采集时延 压缩时延 解压时延 音频回放时延
　　约120ms 约5ms 约5ms 约130ms
　　根据实验结果，我们可以看出采用DirectSound的程序时延要明显小于采用WaveX的程序。
　　此外，还可以采用ASIO（Audio Stream Input Output，音频流输入输出接口）方式。ASIO可以增强声卡硬件的处理能力，极大的减少系统对音频流信号的延迟，ASIO的音频采集时延可缩短为几个毫秒。但其需要专业声卡的支持，使用复杂，实现起来比较困难。
　　5、结束语
　　本文对局域网环境中的VoIP应用进行了端到端时延分析，并通过实验验证了以太网环境下音频传输时延主要由缓冲区时延和API调用时延构成的，其中最主要的部分是API调用时延。所以，在进行以太网VoIP应用系统开发时，要重点考虑优化上述两部分的实现策略以提高话音质量。