以太网环境下实时音频传输的研究
时间:09-21
来源:互联网
点击:
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应用系统开发时,要重点考虑优化上述两部分的实现策略以提高话音质量。
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应用系统开发时,要重点考虑优化上述两部分的实现策略以提高话音质量。
示波器 相关文章:
- 基于MSP430单片机和nRF905的无线通信系统(06-18)
- IPTV测试仪网络层测试的设计与实现(08-11)
- 简化USB 3.0系统的均衡设计(12-14)
- 学习CAN应用设计中的心得体会(转)(01-05)
- 嵌入式系统的PCIe时钟分配(12-09)
- 基于CPLD的OMAP-L137与ADS1178数据通信设计(01-14)
