隨著網(wǎng)絡(luò)技術(shù)的快速發(fā)展，VoIP技術(shù)得到了廣泛的應(yīng)用。特別是在局域網(wǎng)環(huán)境下，VoIP憑借其應(yīng)用便捷，價(jià)格低廉的優(yōu)點(diǎn)，已經(jīng)成為了人們即時(shí)交流的主要方式之一。從實(shí)際應(yīng)用效果來看，時(shí)延成為影響VoIP話音質(zhì)量的關(guān)鍵因素。ITU-TG.114規(guī)定，對于高質(zhì)量語音可接受的時(shí)延是300 ms。一般來說，如果時(shí)延在300～400 ms，通話的交互性比較差，但還可以接受。時(shí)延大于400 ms時(shí)，則交互通信非常困難，所以如何確保音頻實(shí)時(shí)傳輸已經(jīng)成為VoIP技術(shù)中首要解決的問題之一。 　　本文首先介紹了VoIP原理和基本實(shí)現(xiàn)流程，然后對以太網(wǎng)環(huán)境下實(shí)時(shí)音頻傳輸進(jìn)行了實(shí)驗(yàn)研究，分析了緩沖區(qū)設(shè)置和音頻API調(diào)用對音頻時(shí)延的影響，并根據(jù)分析結(jié)果，提出了解決以太網(wǎng)音頻時(shí)延的對策。 1、VoIP原理及其基于PC平臺(tái)的實(shí)現(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平臺(tái)的VoIP實(shí)現(xiàn)流程。如圖所示，基于PC平臺(tái)的VoIP應(yīng)用的基本實(shí)現(xiàn)包括接收模塊、發(fā)送模塊和網(wǎng)絡(luò)傳輸三部分構(gòu)成。其中，發(fā)送模塊主要由音頻采集、音頻編碼、分組話音封裝等部分組成。接收模塊的實(shí)現(xiàn)過程一般由發(fā)送模塊的逆過程構(gòu)成，主要包括分組話音的接收，音頻解碼及音頻播放等部分組成。 [/align]　　下面分別介紹各部分功能以及常規(guī)的實(shí)現(xiàn)方式。 　　音頻采集和播放模塊主要對音頻信號進(jìn)行采集和回放操作，完成模擬語音和數(shù)字語音之間的轉(zhuǎn)換。它主要通過音頻API函數(shù)來實(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)的報(bào)頭，使其成為一個(gè)語音包，然后送給傳輸模塊。TCP/IP協(xié)議體系中有兩個(gè)不同的傳輸層協(xié)議，分別是面向連接的傳輸控制協(xié)議TCP和無連接的用戶數(shù)據(jù)報(bào)協(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é)議。這是因?yàn)殡m然UDP協(xié)議不提供錯(cuò)誤重傳的功能，但是它可以保證音頻數(shù)據(jù)的實(shí)時(shí)性。 　　網(wǎng)絡(luò)傳輸模塊就是將封裝好的IP語音數(shù)據(jù)包從發(fā)送端發(fā)往接收端。在Windows操作系統(tǒng)中，主要通過Winsock函數(shù)來完成。 2、緩沖區(qū)大小與時(shí)延的關(guān)系 　　緩沖區(qū)大小與時(shí)延有著密切的關(guān)系。一般來說，緩沖區(qū)大時(shí)，時(shí)延較大，但是可以有效地進(jìn)行失序重組等操作，話音質(zhì)量較好；緩沖區(qū)較小時(shí)，時(shí)延較小，但由于緩沖并沒有很好地消除時(shí)延抖動(dòng)等因素，導(dǎo)致話音質(zhì)量較差。所以要將緩沖設(shè)為合適的大小，使得時(shí)延較小，同時(shí)又保持著較好的語音質(zhì)量。 　　實(shí)驗(yàn)程序是我們前期編寫的PCtoPC的VoIP程序，是由VC++編寫的，使用低階的音頻API-WaveX函數(shù)來實(shí)現(xiàn)音頻的采集和回放；使用ACM來進(jìn)行語音的壓縮和解壓縮；使用Winsock來進(jìn)行網(wǎng)絡(luò)通信。實(shí)驗(yàn)程序?qū)崿F(xiàn)了網(wǎng)絡(luò)語音傳輸?shù)幕竟δ?，程序中采集和回放緩沖區(qū)大小相同，個(gè)數(shù)均為2，采用乒乓制。 　　我們在以太網(wǎng)環(huán)境下對緩沖區(qū)大小與端到端時(shí)延的關(guān)系進(jìn)行了測量。其中端到端時(shí)延測量的思路是：運(yùn)行程序，從麥克風(fēng)輸入一個(gè)激勵(lì)，從耳機(jī)端得到一個(gè)輸出，如果能獲得兩者時(shí)間之差即為端到端時(shí)延?？梢栽诒緳C(jī)撥打本機(jī)運(yùn)行測試，這樣不需要考慮同步的問題，而且由于測試環(huán)境基于100Mbit/s以太網(wǎng)鏈路，鏈路傳輸時(shí)延為微秒級，可以忽略不計(jì)，所以本機(jī)環(huán)回測試得出的結(jié)果基本可以表征端到端時(shí)延。測量的具體方法是通過示波器，產(chǎn)生一個(gè)適當(dāng)?shù)男盘?，模擬語音輸入，然后觀察輸出，得到兩者時(shí)延。測試程序中使用的編解碼算法是GSM610，參數(shù)為 11.025kHz的采樣頻率，8位單聲道方式，音頻API為 WaveX的情況下進(jìn)行了測量，實(shí)驗(yàn)結(jié)果如表1所示。 　　表1　緩沖區(qū)大小與時(shí)延關(guān)系 　　緩沖區(qū)大?。╞yte） 　512 768 1024 1536 2048 4096 　　語音的時(shí)長（ms） 　　46 70 93 140 196 392 　　測得的端到端時(shí)延（ms） 約350 約400 約500 約600 約700 約800 　　在上述測試環(huán)境中，每個(gè)樣本點(diǎn)量化為一個(gè)字節(jié)，采樣頻率為11.025kHz，每秒鐘產(chǎn)生的原始語音數(shù)據(jù)的大小為11025字節(jié)。語音的時(shí)長為緩沖區(qū)大小除以11025，所以語音時(shí)長也應(yīng)是緩沖區(qū)時(shí)延。 　　在實(shí)驗(yàn)中，我們發(fā)現(xiàn)，當(dāng)緩沖區(qū)為512字節(jié)時(shí)，雖然能夠獲得較小的緩沖時(shí)延，但此時(shí)話音的停頓感非常明顯，音質(zhì)很差。而如果將緩沖區(qū)設(shè)置為768字節(jié)，那么音質(zhì)可以得到明顯改善，但是并未增加多少打包時(shí)延，因此在后期實(shí)驗(yàn)中我們將緩沖區(qū)設(shè)置為768字節(jié)。 　　從表1中可以看出，當(dāng)緩沖區(qū)增大時(shí)，時(shí)延明顯增大。但當(dāng)緩沖區(qū)相當(dāng)?。?12字節(jié)）時(shí)，時(shí)延并沒有顯著降低，穩(wěn)定在350ms左右，而相應(yīng)的語音時(shí)長只有53ms。顯然，除了緩沖區(qū)打包和傳輸之外，VoIP傳輸通路中的其他因素也引入了較大的時(shí)延。本文的第三部分將對端到端時(shí)延的具體構(gòu)成作詳細(xì)分析。 3、以太網(wǎng)環(huán)境下時(shí)延的構(gòu)成 　　VoIP中的時(shí)延存在于整個(gè)IP電話的各個(gè)環(huán)節(jié)，如圖2所標(biāo)示，可以大致分為4個(gè)部分：（1）音頻采集和播放時(shí)延。為音頻API引起。（2）緩沖時(shí)延。緩沖時(shí)延是發(fā)送端緩沖區(qū)中排除等待時(shí)間和接收端拆包時(shí)引入的時(shí)延。如本文第2節(jié)中實(shí)驗(yàn)所示，緩沖時(shí)延與緩沖區(qū)大小有關(guān)。（3）語音編/解碼時(shí)延。由語音編碼算法引起，根據(jù)不同的算法，其值也不同，但差距不大，經(jīng)驗(yàn)值在5～40ms之間。（4）網(wǎng)絡(luò)傳輸時(shí)延。網(wǎng)絡(luò)傳輸時(shí)延是數(shù)據(jù)通過網(wǎng)絡(luò)傳輸?shù)竭_(dá)目的地所需的時(shí)間。 [/align] 　　由于以太網(wǎng)帶寬較大距離較近，網(wǎng)絡(luò)時(shí)延一般情況下小于1 ms，可以忽略不計(jì)，所以在局域網(wǎng)環(huán)境下的VoIP的時(shí)延主要是由語音編/解碼時(shí)延、打包/緩沖時(shí)延和音頻采集和播放時(shí)延構(gòu)成的。 　　為了進(jìn)一步確定在以太網(wǎng)條件下VoIP各部分時(shí)延的分布情況，我們通過使用QueryPerformanceCounter函數(shù)在實(shí)驗(yàn)程序中設(shè)置時(shí)戳進(jìn)行了具體的實(shí)驗(yàn)分析。QueryPerformanceCounter函數(shù)可以精確的計(jì)時(shí)。我們在本機(jī)進(jìn)行環(huán)回通話測試，編解碼方式為 GSM610，參數(shù)為11.025kHz的采樣頻率，8位單聲道方式，緩沖區(qū)為768字節(jié)，音頻API為WaveX的情況下，對程序的音頻采集部分，壓縮部分，解壓部分，音頻回放部分進(jìn)行了時(shí)延測量。實(shí)驗(yàn)中原始音頻數(shù)據(jù)為一個(gè)緩沖區(qū)大小。實(shí)驗(yàn)結(jié)果如表2所示： 　　表2　采用WaveX的程序各部分時(shí)延構(gòu)成 　　音頻采集時(shí)延 壓縮時(shí)延 解壓時(shí)延 音頻回放時(shí)延 　　約180ms 　　約5ms 　　約5ms 　　約200ms 　　我們通過將各部分時(shí)延相加，可得到端到端時(shí)延約為390ms。這與本文第2節(jié)中的實(shí)驗(yàn)結(jié)果基本一致，說明我們的實(shí)驗(yàn)結(jié)果是可信的。根據(jù)實(shí)驗(yàn)結(jié)果，我們可以看出時(shí)延的主要組成來自于音頻采集時(shí)延和音頻回放時(shí)延，分別除去緩沖區(qū)時(shí)延（語音時(shí)長）93ms后，還有約200ms，這部分應(yīng)為低階音頻 API-WaveX所導(dǎo)致的。 4、解決以太網(wǎng)時(shí)延對策分析 　　根據(jù)第3節(jié)的實(shí)驗(yàn)結(jié)果，為了縮小時(shí)延，我們必須考慮使用性能的更好的音頻API。 　　我們對程序進(jìn)行了修改，使用DirectSound替代WaveX進(jìn)行音頻的采集和播放。WaveX沒有硬件加速功能，CPU利用率較高，延時(shí)較大。DirectSound是DirectX API的音頻組件之一，它可以提供快速的混音，硬件加速功能，并且可以直接訪問相關(guān)設(shè)備。DirectSound允許進(jìn)行波型聲音的捕獲，重放，也可以通過控制硬件和相應(yīng)的驅(qū)動(dòng)來獲得更多的服務(wù)。DirectSound與WaveX相比技術(shù)較新，功能強(qiáng)大，能夠支持混音，硬件加速操作，采集和播放時(shí)產(chǎn)生的延時(shí)較小。 　　下面簡要介紹一下實(shí)現(xiàn)DirectSound的步驟：DirectSound采集聲音流程如圖3所示，其中DirectSoundCaptureEnumerate函數(shù)用來枚舉系統(tǒng)中所有錄音設(shè)備，DirectSoundCaptureCreat函數(shù)創(chuàng)建設(shè)備對象，然后通過CreatCaptureBuffer函數(shù)來創(chuàng)建一個(gè)錄音的緩存對象，Se tNotificationPositon函數(shù)用于設(shè)置通知位，以便定期的從錄音緩存中拷貝數(shù)據(jù)。DirectSound播放聲音流程如圖4所示，其中DirectSoundCapture、 DirectSoundCreat和CreatSoundBuffer函數(shù)也是做一些初始化的工作。Lock函數(shù)用于鎖住緩存的位置。然后通過 WriteBuffer函數(shù)將音頻數(shù)據(jù)寫入緩沖區(qū)，寫完后再通過UnLock函數(shù)解鎖。 　　我們在與第3節(jié)相同的實(shí)驗(yàn)環(huán)境下，對采用DirectSound的程序進(jìn)行了時(shí)延測量，通過示波器測得的端到端時(shí)延約為250ms左右，時(shí)戳測量的結(jié)果如表3所示。 　　表3　采用DirectSound的程序各部分時(shí)延構(gòu)成 　　音頻采集時(shí)延 壓縮時(shí)延 解壓時(shí)延 音頻回放時(shí)延 　　約120ms 　　約5ms 　　約5ms 　約130ms 　　根據(jù)實(shí)驗(yàn)結(jié)果，我們可以看出采用DirectSound的程序時(shí)延要明顯小于采用WaveX的程序。 　　此外，還可以采用ASIO（Audio Stream Input Output，音頻流輸入輸出接口）方式。ASIO可以增強(qiáng)聲卡硬件的處理能力，極大的減少系統(tǒng)對音頻流信號的延遲，ASIO的音頻采集時(shí)延可縮短為幾個(gè)毫秒。但其需要專業(yè)聲卡的支持，使用復(fù)雜，實(shí)現(xiàn)起來比較困難。 5、結(jié)束語 　　本文對局域網(wǎng)環(huán)境中的VoIP應(yīng)用進(jìn)行了端到端時(shí)延分析，并通過實(shí)驗(yàn)驗(yàn)證了以太網(wǎng)環(huán)境下音頻傳輸時(shí)延主要由緩沖區(qū)時(shí)延和API調(diào)用時(shí)延構(gòu)成的，其中最主要的部分是API調(diào)用時(shí)延。所以，在進(jìn)行以太網(wǎng)VoIP應(yīng)用系統(tǒng)開發(fā)時(shí)，要重點(diǎn)考慮優(yōu)化上述兩部分的實(shí)現(xiàn)策略以提高話音質(zhì)量。