以太網(wǎng)環(huán)境下實(shí)時(shí)音頻傳輸的研究

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

1、VoIP原理及其基于PC平臺的實(shí)現流程

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

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

圖1　基于PC平臺的VoIP實(shí)現流程

下面分別介紹各部分功能以及常規的實(shí)現方式。

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

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

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

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

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

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

實(shí)驗程序是我們前期編寫(xiě)的PCtoPC的VoIP程序，是由VC++編寫(xiě)的，使用低階的音頻API-WaveX函數來(lái)實(shí)現音頻的采集和回放；使用ACM來(lái)進(jìn)行語(yǔ)音的壓縮和解壓縮；使用Winsock來(lái)進(jìn)行網(wǎng)絡(luò )通信。實(shí)驗程序實(shí)現了網(wǎng)絡(luò )語(yǔ)音傳輸的基本功能，程序中采集和回放緩沖區大小相同，個(gè)數均為2，采用乒乓制。

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

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

緩沖區大?。╞yte） 　512 768 1024 1536 2048 4096
語(yǔ)音的時(shí)長(cháng)（ms） 　　46 70 93 140 196 392
測得的端到端時(shí)延(ms) 約350 約400 約500 約600 約700 約800

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

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

從表1中可以看出，當緩沖區增大時(shí)，時(shí)延明顯增大。但當緩沖區相當?。?12字節）時(shí)，時(shí)延并沒(méi)有顯著(zhù)降低，穩定在350ms左右，而相應的語(yǔ)音時(shí)長(cháng)只有53ms。顯然，除了緩沖區打包和傳輸之外，VoIP傳輸通路中的其他因素也引入了較大的時(shí)延。本文的第三部分將對端到端時(shí)延的具體構成作詳細分析。

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

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

圖2　VoIP時(shí)延分布

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

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

表2　采用WaveX的程序各部分時(shí)延構成

音頻采集時(shí)延 壓縮時(shí)延 解壓時(shí)延 音頻回放時(shí)延
約180ms 約5ms 約5ms 約200ms

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

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

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

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

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

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

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

表3　采用DirectSound的程序各部分時(shí)延構成

音頻采集時(shí)延 壓縮時(shí)延 解壓時(shí)延 音頻回放時(shí)延
約120ms 約5ms 約5ms 約130ms

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

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

5、結束語(yǔ)

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