隨著網(wǎng)絡(luò)技術(shù)的快速發(fā)展，VoIP技術(shù)得到了廣泛的應(yīng)用。特別是在局域網(wǎng)環(huán)境下，VoIP憑借其應(yīng)用便捷，價格低廉的優(yōu)點，已經(jīng)成為了人們即時交流的主要方式之一。從實際應(yīng)用效果來看，時延成為影響VoIP話音質(zhì)量的關(guān)鍵因素。ITU-TG.114規(guī)定，對于高質(zhì)量語音可接受的時延是300 ms。一般來說，如果時延在300～400 ms，通話的交互性比較差，但還可以接受。時延大于400 ms時，則交互通信非常困難，所以如何確保音頻實時傳輸已經(jīng)成為VoIP技術(shù)中首要解決的問題之一。

本文首先介紹了VoIP原理和基本實現(xiàn)流程，然后對以太網(wǎng)環(huán)境下實時音頻傳輸進(jìn)行了實驗研究，分析了緩沖區(qū)設(shè)置和音頻API調(diào)用對音頻時延的影響，并根據(jù)分析結(jié)果，提出了解決以太網(wǎng)音頻時延的對策。

1、VoIP原理及其基于PC平臺的實現(xiàn)流程

VoIP的基本原理是：發(fā)送端通過語音的壓縮算法對采集到的原始語音數(shù)據(jù)進(jìn)行壓縮處理，然后把這些壓縮后的語音數(shù)據(jù)按TCP/IP標(biāo)準(zhǔn)進(jìn)行打包，經(jīng)過IP網(wǎng)絡(luò)把數(shù)據(jù)包發(fā)送至接收端；接收端將分組話音重組，經(jīng)過解壓處理后，恢復(fù)成原來的語音信號，從而達(dá)到由網(wǎng)絡(luò)傳送語音的目的。

圖1為基于PC平臺的VoIP實現(xiàn)流程。如圖所示，基于PC平臺的VoIP應(yīng)用的基本實現(xiàn)包括接收模塊、發(fā)送模塊和網(wǎng)絡(luò)傳輸三部分構(gòu)成。其中，發(fā)送模塊主要由音頻采集、音頻編碼、分組話音封裝等部分組成。接收模塊的實現(xiàn)過程一般由發(fā)送模塊的逆過程構(gòu)成，主要包括分組話音的接收，音頻解碼及音頻播放等部分組成。

圖1基于PC平臺的VoIP實現(xiàn)流程

下面分別介紹各部分功能以及常規(guī)的實現(xiàn)方式。

音頻采集和播放模塊主要對音頻信號進(jìn)行采集和回放操作，完成模擬語音和數(shù)字語音之間的轉(zhuǎn)換。它主要通過音頻API函數(shù)來實現(xiàn)其功能。在Windows操作系統(tǒng)中，常見的音頻API函數(shù)有：WaveX、DirectSound和ASIO等。

音頻編碼與解碼模塊主要完成對語音數(shù)據(jù)的壓縮與解壓功能。在發(fā)送端由于采集到的原始語音數(shù)據(jù)量比較大，需要對原始語音數(shù)據(jù)以特定的音頻格式進(jìn)行壓縮編碼。同理，在接收端需要對接收到的語音數(shù)據(jù)進(jìn)行解壓還原。在Windows操作系統(tǒng)中，ACM（Audio Compression Manager，音頻壓縮管理器）管理著系統(tǒng)中的所有音頻編碼譯碼器（CODEC），負(fù)責(zé)對語音數(shù)據(jù)進(jìn)行壓縮與解壓縮。CODEC是一小段用于壓縮（Compress）及解壓縮（Decompress）數(shù)據(jù)流的代碼。CODEC可以是由操作系統(tǒng)本身附帶的CODEC，也可由系統(tǒng)中所安裝的應(yīng)用程序安裝其他的CODEC。

分組話音封裝和分組話音接收模塊主要是為壓縮后的語音數(shù)據(jù)加上相應(yīng)的報頭，使其成為一個語音包，然后送給傳輸模塊。TCP/IP協(xié)議體系中有兩個不同的傳輸層協(xié)議，分別是面向連接的傳輸控制協(xié)議TCP和無連接的用戶數(shù)據(jù)報協(xié)議UDP。這兩種協(xié)議的不同之處在于UDP提供無連接的服務(wù)，在傳輸數(shù)據(jù)之前不需要先建立連接，遠(yuǎn)程主機(jī)接收到UDP數(shù)據(jù)后，不需要給出任何確認(rèn)；而TCP則提供面向連接的服務(wù)，在傳送數(shù)據(jù)之前必須先建立連接，數(shù)據(jù)傳送結(jié)束后要釋放連接。對于音頻應(yīng)用來說，一般使用UDP協(xié)議。這是因為雖然UDP協(xié)議不提供錯誤重傳的功能，但是它可以保證音頻數(shù)據(jù)的實時性。

網(wǎng)絡(luò)傳輸模塊就是將封裝好的IP語音數(shù)據(jù)包從發(fā)送端發(fā)往接收端。在Windows操作系統(tǒng)中，主要通過Winsock函數(shù)來完成。

2、緩沖區(qū)大小與時延的關(guān)系

緩沖區(qū)大小與時延有著密切的關(guān)系。一般來說，緩沖區(qū)大時，時延較大，但是可以有效地進(jìn)行失序重組等操作，話音質(zhì)量較好；緩沖區(qū)較小時，時延較小，但由于緩沖并沒有很好地消除時延抖動等因素，導(dǎo)致話音質(zhì)量較差。所以要將緩沖設(shè)為合適的大小，使得時延較小，同時又保持著較好的語音質(zhì)量。

實驗程序是我們前期編寫的PCtoPC的VoIP程序，是由VC++編寫的，使用低階的音頻API-WaveX函數(shù)來實現(xiàn)音頻的采集和回放；使用ACM來進(jìn)行語音的壓縮和解壓縮；使用Winsock來進(jìn)行網(wǎng)絡(luò)通信。實驗程序?qū)崿F(xiàn)了網(wǎng)絡(luò)語音傳輸?shù)幕竟δ埽绦蛑胁杉突胤啪彌_區(qū)大小相同，個數(shù)均為2，采用乒乓制。

我們在以太網(wǎng)環(huán)境下對緩沖區(qū)大小與端到端時延的關(guān)系進(jìn)行了測量。其中端到端時延測量的思路是：運行程序，從麥克風(fēng)輸入一個激勵，從耳機(jī)端得到一個輸出，如果能獲得兩者時間之差即為端到端時延。可以在本機(jī)撥打本機(jī)運行測試，這樣不需要考慮同步的問題，而且由于測試環(huán)境基于100Mbit/s以太網(wǎng)鏈路，鏈路傳輸時延為微秒級，可以忽略不計，所以本機(jī)環(huán)回測試得出的結(jié)果基本可以表征端到端時延。測量的具體方法是通過示波器，產(chǎn)生一個適當(dāng)?shù)男盘枺M語音輸入，然后觀察輸出，得到兩者時延。測試程序中使用的編解碼算法是GSM610，參數(shù)為 11.025kHz的采樣頻率，8位單聲道方式，音頻API為 WaveX的情況下進(jìn)行了測量，實驗結(jié)果如表1所示。

表1緩沖區(qū)大小與時延關(guān)系

緩沖區(qū)大小（byte） 512 768 1024 1536 2048 4096

語音的時長（ms） 46 70 93 140 196 392

測得的端到端時延（ms） 約350 約400 約500 約600 約700 約800

在上述測試環(huán)境中，每個樣本點量化為一個字節(jié)，采樣頻率為11.025kHz，每秒鐘產(chǎn)生的原始語音數(shù)據(jù)的大小為11025字節(jié)。語音的時長為緩沖區(qū)大小除以11025，所以語音時長也應(yīng)是緩沖區(qū)時延。

在實驗中，我們發(fā)現(xiàn)，當(dāng)緩沖區(qū)為512字節(jié)時，雖然能夠獲得較小的緩沖時延，但此時話音的停頓感非常明顯，音質(zhì)很差。而如果將緩沖區(qū)設(shè)置為768字節(jié)，那么音質(zhì)可以得到明顯改善，但是并未增加多少打包時延，因此在后期實驗中我們將緩沖區(qū)設(shè)置為768字節(jié)。

從表1中可以看出，當(dāng)緩沖區(qū)增大時，時延明顯增大。但當(dāng)緩沖區(qū)相當(dāng)小（512字節(jié)）時，時延并沒有顯著降低，穩(wěn)定在350ms左右，而相應(yīng)的語音時長只有53ms。顯然，除了緩沖區(qū)打包和傳輸之外，VoIP傳輸通路中的其他因素也引入了較大的時延。本文的第三部分將對端到端時延的具體構(gòu)成作詳細(xì)分析。

3、以太網(wǎng)環(huán)境下時延的構(gòu)成

VoIP中的時延存在于整個IP電話的各個環(huán)節(jié)，如圖2所標(biāo)示，可以大致分為4個部分：（1）音頻采集和播放時延。為音頻API引起。（2）緩沖時延。緩沖時延是發(fā)送端緩沖區(qū)中排除等待時間和接收端拆包時引入的時延。如本文第2節(jié)中實驗所示，緩沖時延與緩沖區(qū)大小有關(guān)。（3）語音編/解碼時延。由語音編碼算法引起，根據(jù)不同的算法，其值也不同，但差距不大，經(jīng)驗值在5～40ms之間。（4）網(wǎng)絡(luò)傳輸時延。網(wǎng)絡(luò)傳輸時延是數(shù)據(jù)通過網(wǎng)絡(luò)傳輸?shù)竭_(dá)目的地所需的時間。

圖2VoIP時延分布

由于以太網(wǎng)帶寬較大距離較近，網(wǎng)絡(luò)時延一般情況下小于1 ms，可以忽略不計，所以在局域網(wǎng)環(huán)境下的VoIP的時延主要是由語音編/解碼時延、打包/緩沖時延和音頻采集和播放時延構(gòu)成的。

為了進(jìn)一步確定在以太網(wǎng)條件下VoIP各部分時延的分布情況，我們通過使用QueryPerformanceCounter函數(shù)在實驗程序中設(shè)置時戳進(jìn)行了具體的實驗分析。QueryPerformanceCounter函數(shù)可以精確的計時。我們在本機(jī)進(jìn)行環(huán)回通話測試，編解碼方式為 GSM610，參數(shù)為11.025kHz的采樣頻率，8位單聲道方式，緩沖區(qū)為768字節(jié)，音頻API為WaveX的情況下，對程序的音頻采集部分，壓縮部分，解壓部分，音頻回放部分進(jìn)行了時延測量。實驗中原始音頻數(shù)據(jù)為一個緩沖區(qū)大小。實驗結(jié)果如表2所示：

表2采用WaveX的程序各部分時延構(gòu)成

音頻采集時延 壓縮時延 解壓時延 音頻回放時延

約180ms 約5ms 約5ms 約200ms

我們通過將各部分時延相加，可得到端到端時延約為390ms。這與本文第2節(jié)中的實驗結(jié)果基本一致，說明我們的實驗結(jié)果是可信的。根據(jù)實驗結(jié)果，我們可以看出時延的主要組成來自于音頻采集時延和音頻回放時延，分別除去緩沖區(qū)時延（語音時長）93ms后，還有約200ms，這部分應(yīng)為低階音頻 API-WaveX所導(dǎo)致的。

4、解決以太網(wǎng)時延對策分析

根據(jù)第3節(jié)的實驗結(jié)果，為了縮小時延，我們必須考慮使用性能的更好的音頻API。

我們對程序進(jìn)行了修改，使用DirectSound替代WaveX進(jìn)行音頻的采集和播放。WaveX沒有硬件加速功能，CPU利用率較高，延時較大。DirectSound是DirectX API的音頻組件之一，它可以提供快速的混音，硬件加速功能，并且可以直接訪問相關(guān)設(shè)備。DirectSound允許進(jìn)行波型聲音的捕獲，重放，也可以通過控制硬件和相應(yīng)的驅(qū)動來獲得更多的服務(wù)。DirectSound與WaveX相比技術(shù)較新，功能強(qiáng)大，能夠支持混音，硬件加速操作，采集和播放時產(chǎn)生的延時較小。

下面簡要介紹一下實現(xiàn)DirectSound的步驟：DirectSound采集聲音流程如圖3所示，其中 DirectSoundCaptureEnumerate函數(shù)用來枚舉系統(tǒng)中所有錄音設(shè)備，DirectSoundCaptureCreat函數(shù)創(chuàng)建設(shè)備對象，然后通過CreatCaptureBuffer函數(shù)來創(chuàng)建一個錄音的緩存對象，Se tNotificationPositon函數(shù)用于設(shè)置通知位，以便定期的從錄音緩存中拷貝數(shù)據(jù)。DirectSound播放聲音流程如圖4所示，其中DirectSoundCapture、 DirectSoundCreat和CreatSoundBuffer函數(shù)也是做一些初始化的工作。Lock函數(shù)用于鎖住緩存的位置。然后通過 WriteBuffer函數(shù)將音頻數(shù)據(jù)寫入緩沖區(qū)，寫完后再通過UnLock函數(shù)解鎖。

圖3采集聲音流程圖4播放聲音流程

我們在與第3節(jié)相同的實驗環(huán)境下，對采用DirectSound的程序進(jìn)行了時延測量，通過示波器測得的端到端時延約為250ms左右，時戳測量的結(jié)果如表3所示。

表3采用DirectSound的程序各部分時延構(gòu)成

音頻采集時延 壓縮時延 解壓時延 音頻回放時延

約120ms 約5ms 約5ms 約130ms

根據(jù)實驗結(jié)果，我們可以看出采用DirectSound的程序時延要明顯小于采用WaveX的程序。

此外，還可以采用ASIO（Audio Stream Input Output，音頻流輸入輸出接口）方式。ASIO可以增強(qiáng)聲卡硬件的處理能力，極大的減少系統(tǒng)對音頻流信號的延遲，ASIO的音頻采集時延可縮短為幾個毫秒。但其需要專業(yè)聲卡的支持，使用復(fù)雜，實現(xiàn)起來比較困難。

5、結(jié)束語

本文對局域網(wǎng)環(huán)境中的VoIP應(yīng)用進(jìn)行了端到端時延分析，并通過實驗驗證了以太網(wǎng)環(huán)境下音頻傳輸時延主要由緩沖區(qū)時延和API調(diào)用時延構(gòu)成的，其中最主要的部分是API調(diào)用時延。所以，在進(jìn)行以太網(wǎng)VoIP應(yīng)用系統(tǒng)開發(fā)時，要重點考慮優(yōu)化上述兩部分的實現(xiàn)策略以提高話音質(zhì)量。

責(zé)任編輯：gt