乙太網路環境下即時音頻傳輸的研究

摘要　本文對VoIP原理和基本實現流程做了介紹，並對乙太網路環境下音頻時延構成進行了分析。實驗結果證明乙太網路環境下音頻時延主要由緩衝區時延和API調用時延構成，其中最主要的部分是API調用時延。論文提出了採用DirectSound介面函數降低API調用時延的方法，並對進一步降低API時延策略進行了探討。

　　隨著網路技術的快速發展，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函數來建立一個錄音的緩衝對象，SetNotificationPositon函數用於設定通知位，以便週期性從錄音緩衝中拷貝資料。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應用系統開發時，要重點考慮最佳化上述兩部分的實現策略以提高話音品質。