Windows CE下實現VoIP的技術研究

張愛民

(總參謀部通信訓練基地)

張愛民(講師),研究方向為軍用無線通信與網絡、通信抗干擾技術。

引 言

隨著互聯網的快速發展和語音信號處理的進步,嵌入式網絡終端的VoIP技術成為目前國內外研究熱點問題之一。與傳統的電話網絡相比,VoIP具有占用網絡資源少、成本低等優勢,而嵌入式設備具有的便攜、高可靠、低成本和低功耗的特性,使得嵌入式網絡終端的VoIP技術市場潛力巨大。但是,目前存在的VoIP系統軟件(如 Skype網絡電話、UUCall網絡電話、KC網絡電話、Net meeting等)都是基于桌面計算機的,難以運行在嵌入式網絡終端上。許多類庫中的函數在PC上可以正常運行,而Windows CE嵌入式操作系統卻不支持[1],所以研究基于嵌入式網絡的VoIP技術應用有著很重要的意義。

1 嵌入式網絡終端的硬件平臺和操作系統

1.1 硬件平臺

嵌入式網絡終端VoIP的硬件平臺采用三星公司基于ARM11內核(ARM1176JZF-S)的S3C6410作為處理器,其系統結構如圖1所示。S3C6410具有低功耗耗、高性價比的特點,可廣泛應用于移動電話和通用處理等領域。S3C6410為2.5G和3G通信服務提供了優化的硬件性能,內置強大的硬件加速器,包括運動視頻處理、音頻處理、2D加速、顯示處理和縮放等;集成了一個 MFC(Multi-Format video Codec),能夠支持MPEG4/H.263/H.264編解碼和VC1的解碼;包含了優化的外部存儲器接口,該接口能滿足在高端通信服務中的數據帶寬要求,能夠進行實時的視頻會議。蘋果公司的iPhone手機就是基于 S3C6410處理器。另外,目前基于 S3C6410的OK6410開發板上集成了以太網接口、視頻等多種高端接口,還可連接Wi-Fi模塊 、GPRS模塊和 3G模塊,為 VoIP提供了強大的組網通信能力。

圖1 硬件平臺系統結構

1.2 操作系統

Windows CE是Microsoft公司專門針對嵌入式產品領域開發的一種緊湊、高效、可伸縮的32位操作系統,主要面向各種嵌入式系統和產品。它所具有的多線程、多任務、完全搶占式的特點是專門為各種有嚴格限制的硬件系統所設計的。Windows CE的模塊化設計使嵌入式系統和應用程序開發者能夠方便地加以定制以適應一系列產品,例如消費類電子設備、專用工業控制器和嵌入式通信設備等。VoIP是Windows CE6.0持續加強的重點,除了應用程序層更進一步的整合外,操作系統核心也具備了直接支持的能力,硬件開發人員更容易在Windows CE下進行網絡語音的開發;在網絡堆疊協議方面,Windows CE6.0直接支持了802.11i、802.11e和WAP2等協議。

2 嵌入式網絡終端的軟件設計

ITU-TG.114規定,高質量語音可接受的時延是300 ms。同時ITU-TG.114提出,對于VoIP網絡來說,單向的時延門限為400 ms。但實際上語音信號在端到端傳輸過程中產生的時延有編解碼時延、語音采集和播放時延、分組打包時延、網絡傳輸時延、緩沖排隊時延和處理時延等,這些時延共同作用影響語音信號質量。與數據信號相比,語音信號對丟包和誤碼不是非常敏感。對于IP包的丟失,典型的語音編碼可以允許包丟失率為3%。采取一些特殊措施后,包丟失率達到8%～10%尚可容忍[2]。所以時延是VoIP要解決的最大問題。

2.1 VoⅠP語音的采集和播放

Windows CE下語音采集和語音播放主要有兩種方式:一種是采用低階音頻函數WaveX系列API函數來完成,另一種是采用DirectSound技術來完成。WaveX沒有硬件加速功能,CPU利用率較高,延時較大。DirectSound是DirectX API的音頻組件之一,它可以提供快速混音和硬件加速功能,并且可以直接訪問相關設備。DirectSound與WaveX相比,功能強大,硬件加速操作,采集和播放時產生的延時較小[3],所以這里采用DirectSound來進行音頻數據的采集和播放。

首先分析聲音采集的基本步驟:

①調用DirectSoundCaptureEnumerate枚舉錄音設備,初始化WAVEFORMATEX結構體設置語音采集的PCM編碼格式,例如采樣頻率、量化位數、聲道等。

②分別調用DirectSoundCaptureCreate8、CreateCaptureBuffer建立采集用的設備對象和緩沖區對象,然后調用SetNotificationPositions設置緩沖區通知,用于當緩沖區的讀指針達到某預設位置時觸發通知事件,提醒我們可以對某部分的數據進行傳送了。

③調用IDirectSoundCaptureBuffer8的成員函數Start、Lock、Unlock、Stop、GetCurrentPosition 來采集聲音。當通知被觸發后,為了防止采集過程被中斷,建立一個新的線程來處理數據傳送的事件。

同樣在語音播放時DirectSound也提供了一系列函數。其中,DirectSoundEnumerate用來枚舉播放設備,DirectSoundCreat和CreatSoundBuffer函數用來建立采播放設備對象和緩沖區對象,IDirectSoundBuffer8的成員函數Lock用來鎖住緩存的位置;通過WriteBuffer函數將音頻數據寫入緩沖區,寫完后再通過 UnLock函數解鎖;調用IDirectSoundBuffer8 的成員函數 Play、Stop、SetCurrent-Position可以播放音頻數據。

2.2 網絡語音數據傳輸

在Windows CE下TCP和UDP是常用的網絡傳輸協議。TCP是一種面向連接的協議,在傳輸數據前建立的是虛鏈路,不能保證各個語音包在相等的時間內到達,所以無法避免話音抖動現象。TCP提供的確認與超時重傳機制、活動窗口機制等用于數據流量控制和擁塞處理,可減少丟包的發生。但正是由于實現的復雜,網絡開銷很大,給數據的傳輸帶來很大的時延,音頻實時傳輸已經成為VoIP技術中首要解決的問題之一。因此TCP協議不適合傳輸實時音頻數據[3]。

UDP提供無連接的數據包傳輸,對網絡的資源占用較少,網絡時延也較小,但可靠性不高,有可能出現語音包的丟失和誤傳。經過長期反復的測試,在局域網內實現VoIP通信,丟包和誤碼率很低,UDP協議完全可以勝任。但是在互聯網上實現VoIP通信,必須解決網絡傳輸不可靠的問題。Windows CE也支持RTP協議,利用RTP協議可以在UDP數據包中添加時問戳和序列號等控制信息,提高網絡傳輸的可靠性。采集的音頻數據包首先以RTP協議進行封裝,再用 UDP協議對RTP數據包進行封裝,最后封裝為IP數據包,經網絡進行傳輸[4]。采用UDP和RTP相結合的方案可以保證網絡數據傳輸可靠,同時也保證了時延不會太大。VoIP通信過程如圖2所示。

采集到的聲音傳輸到網絡的其他終端上才能完成VoIP通信,可采用Socket UDP方式來實現。WinSock犃犘犐中函數封裝了UDP類,可以完成UDP全部操作。首先調用socket函數來創建數據報套接字,然后指定本地端口、遠程端口和遠程ⅠP地址,接著調用sendto函數和recvfrom直接發送數據和接收數據。接收數據時需要單獨創建線程,并通過select事件模型來檢測UDP事件,包括數據接收事件和UDP發生錯誤事件。

圖2 VoⅠP通信過程

2.3 數據緩存區的設置

數據緩存區大小的設置對語音信號的質量會產生很大的影響。錄音數據緩存和編碼緩存區的大小必須適中。

錄音緩沖區過小,生成的語音數據幀也就會過小,語音的連續性遭到破壞,同時數據分組的有效數據率也會過小,增加了網絡負擔[5];如果緩沖區過大,會在語音錄制和其他處理時造成比較大的處理時延,還有可能造成發送的數據分組過大而導致某協議層的數據分割與合并,形成很大的傳輸時延。所以錄音緩沖區要選擇合適的大小,必須在語音的連續性和時延之間進行平衡。在工程實踐中要根據語音效果來確定緩存區的大小。

編碼緩存區的大小取決于錄音緩存區的大小和編碼方式,實際應用中要根據不同的語音編解碼技術設計不同的緩沖區。參考文獻[6]中采用的編解碼算法是GSM610,參數為11.025 kHz的采樣頻率,8位單聲道方式進行語音數據采集,測出不同的緩存區大小帶來的時延。結論是當緩沖區設置為768字節時語音質量比較好,而且時延也可以接受。

結 語

嵌入式網絡終端的VoIP技術實用價值高,市場潛力巨大,但語音質量不高的現狀制約了它的發展。本文針對VoIP時延大的不足,從減小語音采集和播放時延、網絡傳輸時延和緩存區時延三方面入手提出了不同的解決方案,對在基于Windows CE的嵌入式網絡終端上實現VoIP技術具有一定的參考價值。

[1]何花,王平,施文灶,等.基于WINCE 5.0的通信軟件設計[J].電子測量技術,2010,33(11):117-123.

[2]徐勛業,熊中柱,王志軍.VoIP語音時延的分析和研究[J].光通信研究,2007(1):11-14.

[3]肖建榮,胡劍凌,張玫.基于UDP的網絡音頻系統的 研究與實現[J].電聲技術,2004(5):55-57.

[4]Jill M Boyce.Packet loss resilient transmission of MPEG Video over the Internet[J].Signal Processing:Image Communication,1999(15):7-24.

[5]袁少華.互聯網實時語音通信技術的研究[J].網絡與通信,2006(5):48-49.

[6]王佇,錢新,牛大偉.以太網環境下實時音頻傳輸的研究[J].中國新通信,2007(17):16-18.