隨著網絡技術的快速發展，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應用的基本實現包括接收模塊、發送模塊和網絡傳輸三部分構成。其中，發送模塊主要由音頻采集、音頻編碼、分組話音封裝等部分組成。接收模塊的實現過程一般由發送模塊的逆過程構成，主要包括分組話音的接收，音頻解碼及音頻播放等部分組成。 [/align]　　下面分別介紹各部分功能以及常規的實現方式。 　　音頻采集和播放模塊主要對音頻信號進行采集和回放操作，完成模擬語音和數字語音之間的轉換。它主要通過音頻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）網絡傳輸時延。網絡傳輸時延是數據通過網絡傳輸到達目的地所需的時間。 [/align] 　　由于以太網帶寬較大距離較近，網絡時延一般情況下小于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節相同的實驗環境下，對采用DirectSound的程序進行了時延測量，通過示波器測得的端到端時延約為250ms左右，時戳測量的結果如表3所示。 　　表3　采用DirectSound的程序各部分時延構成 　　音頻采集時延 壓縮時延 解壓時延 音頻回放時延 　　約120ms 　　約5ms 　　約5ms 　約130ms 　　根據實驗結果，我們可以看出采用DirectSound的程序時延要明顯小于采用WaveX的程序。 　　此外，還可以采用ASIO（Audio Stream Input Output，音頻流輸入輸出接口）方式。ASIO可以增強聲卡硬件的處理能力，極大的減少系統對音頻流信號的延遲，ASIO的音頻采集時延可縮短為幾個毫秒。但其需要專業聲卡的支持，使用復雜，實現起來比較困難。 5、結束語 　　本文對局域網環境中的VoIP應用進行了端到端時延分析，并通過實驗驗證了以太網環境下音頻傳輸時延主要由緩沖區時延和API調用時延構成的，其中最主要的部分是API調用時延。所以，在進行以太網VoIP應用系統開發時，要重點考慮優化上述兩部分的實現策略以提高話音質量。