張愛民

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

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

引 言

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

1 嵌入式網(wǎng)絡(luò)終端的硬件平臺和操作系統(tǒng)

1.1 硬件平臺

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

圖1 硬件平臺系統(tǒng)結(jié)構(gòu)

1.2 操作系統(tǒng)

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

2 嵌入式網(wǎng)絡(luò)終端的軟件設(shè)計

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

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

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

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

①調(diào)用DirectSoundCaptureEnumerate枚舉錄音設(shè)備,初始化WAVEFORMATEX結(jié)構(gòu)體設(shè)置語音采集的PCM編碼格式,例如采樣頻率、量化位數(shù)、聲道等。

②分別調(diào)用DirectSoundCaptureCreate8、CreateCaptureBuffer建立采集用的設(shè)備對象和緩沖區(qū)對象,然后調(diào)用SetNotificationPositions設(shè)置緩沖區(qū)通知,用于當(dāng)緩沖區(qū)的讀指針達(dá)到某預(yù)設(shè)位置時觸發(fā)通知事件,提醒我們可以對某部分的數(shù)據(jù)進(jìn)行傳送了。

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

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

2.2 網(wǎng)絡(luò)語音數(shù)據(jù)傳輸

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

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

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

圖2 VoⅠP通信過程

2.3 數(shù)據(jù)緩存區(qū)的設(shè)置

數(shù)據(jù)緩存區(qū)大小的設(shè)置對語音信號的質(zhì)量會產(chǎn)生很大的影響。錄音數(shù)據(jù)緩存和編碼緩存區(qū)的大小必須適中。

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

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

結(jié) 語

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

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

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

[3]肖建榮,胡劍凌,張玫.基于UDP的網(wǎng)絡(luò)音頻系統(tǒng)的 研究與實現(xiàn)[J].電聲技術(shù),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]袁少華.互聯(lián)網(wǎng)實時語音通信技術(shù)的研究[J].網(wǎng)絡(luò)與通信,2006(5):48-49.

[6]王佇,錢新,牛大偉.以太網(wǎng)環(huán)境下實時音頻傳輸?shù)难芯縖J].中國新通信,2007(17):16-18.