張愛民
(總參謀部通信訓(xùn)練基地)
張愛民(講師),研究方向?yàn)檐娪脽o(wú)線通信與網(wǎng)絡(luò)、通信抗干擾技術(shù)。
隨著互聯(lián)網(wǎng)的快速發(fā)展和語(yǔ)音信號(hào)處理的進(jìn)步,嵌入式網(wǎng)絡(luò)終端的VoIP技術(shù)成為目前國(guó)內(nèi)外研究熱點(diǎn)問題之一。與傳統(tǒng)的電話網(wǎng)絡(luò)相比,VoIP具有占用網(wǎng)絡(luò)資源少、成本低等優(yōu)勢(shì),而嵌入式設(shè)備具有的便攜、高可靠、低成本和低功耗的特性,使得嵌入式網(wǎng)絡(luò)終端的VoIP技術(shù)市場(chǎng)潛力巨大。但是,目前存在的VoIP系統(tǒng)軟件(如 Skype網(wǎng)絡(luò)電話、UUCall網(wǎng)絡(luò)電話、KC網(wǎng)絡(luò)電話、Net meeting等)都是基于桌面計(jì)算機(jī)的,難以運(yùn)行在嵌入式網(wǎng)絡(luò)終端上。許多類庫(kù)中的函數(shù)在PC上可以正常運(yùn)行,而Windows CE嵌入式操作系統(tǒng)卻不支持[1],所以研究基于嵌入式網(wǎng)絡(luò)的VoIP技術(shù)應(yīng)用有著很重要的意義。
嵌入式網(wǎng)絡(luò)終端VoIP的硬件平臺(tái)采用三星公司基于ARM11內(nèi)核(ARM1176JZF-S)的S3C6410作為處理器,其系統(tǒng)結(jié)構(gòu)如圖1所示。S3C6410具有低功耗耗、高性價(jià)比的特點(diǎn),可廣泛應(yīng)用于移動(dòng)電話和通用處理等領(lǐng)域。S3C6410為2.5G和3G通信服務(wù)提供了優(yōu)化的硬件性能,內(nèi)置強(qiáng)大的硬件加速器,包括運(yùn)動(dòng)視頻處理、音頻處理、2D加速、顯示處理和縮放等;集成了一個(gè) MFC(Multi-Format video Codec),能夠支持MPEG4/H.263/H.264編解碼和VC1的解碼;包含了優(yōu)化的外部存儲(chǔ)器接口,該接口能滿足在高端通信服務(wù)中的數(shù)據(jù)帶寬要求,能夠進(jìn)行實(shí)時(shí)的視頻會(huì)議。蘋果公司的iPhone手機(jī)就是基于 S3C6410處理器。另外,目前基于 S3C6410的OK6410開發(fā)板上集成了以太網(wǎng)接口、視頻等多種高端接口,還可連接Wi-Fi模塊 、GPRS模塊和 3G模塊,為 VoIP提供了強(qiáng)大的組網(wǎng)通信能力。
圖1 硬件平臺(tái)系統(tǒng)結(jié)構(gòu)
Windows CE是Microsoft公司專門針對(duì)嵌入式產(chǎn)品領(lǐng)域開發(fā)的一種緊湊、高效、可伸縮的32位操作系統(tǒng),主要面向各種嵌入式系統(tǒng)和產(chǎn)品。它所具有的多線程、多任務(wù)、完全搶占式的特點(diǎn)是專門為各種有嚴(yán)格限制的硬件系統(tǒng)所設(shè)計(jì)的。Windows CE的模塊化設(shè)計(jì)使嵌入式系統(tǒng)和應(yīng)用程序開發(fā)者能夠方便地加以定制以適應(yīng)一系列產(chǎn)品,例如消費(fèi)類電子設(shè)備、專用工業(yè)控制器和嵌入式通信設(shè)備等。VoIP是Windows CE6.0持續(xù)加強(qiáng)的重點(diǎn),除了應(yīng)用程序?qū)痈M(jìn)一步的整合外,操作系統(tǒng)核心也具備了直接支持的能力,硬件開發(fā)人員更容易在Windows CE下進(jìn)行網(wǎng)絡(luò)語(yǔ)音的開發(fā);在網(wǎng)絡(luò)堆疊協(xié)議方面,Windows CE6.0直接支持了802.11i、802.11e和WAP2等協(xié)議。
ITU-TG.114規(guī)定,高質(zhì)量語(yǔ)音可接受的時(shí)延是300 ms。同時(shí)ITU-TG.114提出,對(duì)于VoIP網(wǎng)絡(luò)來說,單向的時(shí)延門限為400 ms。但實(shí)際上語(yǔ)音信號(hào)在端到端傳輸過程中產(chǎn)生的時(shí)延有編解碼時(shí)延、語(yǔ)音采集和播放時(shí)延、分組打包時(shí)延、網(wǎng)絡(luò)傳輸時(shí)延、緩沖排隊(duì)時(shí)延和處理時(shí)延等,這些時(shí)延共同作用影響語(yǔ)音信號(hào)質(zhì)量。與數(shù)據(jù)信號(hào)相比,語(yǔ)音信號(hào)對(duì)丟包和誤碼不是非常敏感。對(duì)于IP包的丟失,典型的語(yǔ)音編碼可以允許包丟失率為3%。采取一些特殊措施后,包丟失率達(dá)到8%~10%尚可容忍[2]。所以時(shí)延是VoIP要解決的最大問題。
Windows CE下語(yǔ)音采集和語(yǔ)音播放主要有兩種方式:一種是采用低階音頻函數(shù)WaveX系列API函數(shù)來完成,另一種是采用DirectSound技術(shù)來完成。WaveX沒有硬件加速功能,CPU利用率較高,延時(shí)較大。DirectSound是DirectX API的音頻組件之一,它可以提供快速混音和硬件加速功能,并且可以直接訪問相關(guān)設(shè)備。DirectSound與WaveX相比,功能強(qiáng)大,硬件加速操作,采集和播放時(shí)產(chǎn)生的延時(shí)較小[3],所以這里采用DirectSound來進(jìn)行音頻數(shù)據(jù)的采集和播放。
首先分析聲音采集的基本步驟:
①調(diào)用DirectSoundCaptureEnumerate枚舉錄音設(shè)備,初始化WAVEFORMATEX結(jié)構(gòu)體設(shè)置語(yǔ)音采集的PCM編碼格式,例如采樣頻率、量化位數(shù)、聲道等。
②分別調(diào)用DirectSoundCaptureCreate8、CreateCaptureBuffer建立采集用的設(shè)備對(duì)象和緩沖區(qū)對(duì)象,然后調(diào)用SetNotificationPositions設(shè)置緩沖區(qū)通知,用于當(dāng)緩沖區(qū)的讀指針達(dá)到某預(yù)設(shè)位置時(shí)觸發(fā)通知事件,提醒我們可以對(duì)某部分的數(shù)據(jù)進(jìn)行傳送了。
③調(diào)用IDirectSoundCaptureBuffer8的成員函數(shù)Start、Lock、Unlock、Stop、GetCurrentPosition 來采集聲音。當(dāng)通知被觸發(fā)后,為了防止采集過程被中斷,建立一個(gè)新的線程來處理數(shù)據(jù)傳送的事件。
同樣在語(yǔ)音播放時(shí)DirectSound也提供了一系列函數(shù)。其中,DirectSoundEnumerate用來枚舉播放設(shè)備,DirectSoundCreat和CreatSoundBuffer函數(shù)用來建立采播放設(shè)備對(duì)象和緩沖區(qū)對(duì)象,IDirectSoundBuffer8的成員函數(shù)Lock用來鎖住緩存的位置;通過WriteBuffer函數(shù)將音頻數(shù)據(jù)寫入緩沖區(qū),寫完后再通過 UnLock函數(shù)解鎖;調(diào)用IDirectSoundBuffer8 的成員函數(shù) Play、Stop、SetCurrent-Position可以播放音頻數(shù)據(jù)。
在Windows CE下TCP和UDP是常用的網(wǎng)絡(luò)傳輸協(xié)議。TCP是一種面向連接的協(xié)議,在傳輸數(shù)據(jù)前建立的是虛鏈路,不能保證各個(gè)語(yǔ)音包在相等的時(shí)間內(nèi)到達(dá),所以無(wú)法避免話音抖動(dòng)現(xiàn)象。TCP提供的確認(rèn)與超時(shí)重傳機(jī)制、活動(dòng)窗口機(jī)制等用于數(shù)據(jù)流量控制和擁塞處理,可減少丟包的發(fā)生。但正是由于實(shí)現(xiàn)的復(fù)雜,網(wǎng)絡(luò)開銷很大,給數(shù)據(jù)的傳輸帶來很大的時(shí)延,音頻實(shí)時(shí)傳輸已經(jīng)成為VoIP技術(shù)中首要解決的問題之一。因此TCP協(xié)議不適合傳輸實(shí)時(shí)音頻數(shù)據(jù)[3]。
UDP提供無(wú)連接的數(shù)據(jù)包傳輸,對(duì)網(wǎng)絡(luò)的資源占用較少,網(wǎng)絡(luò)時(shí)延也較小,但可靠性不高,有可能出現(xiàn)語(yǔ)音包的丟失和誤傳。經(jīng)過長(zhǎng)期反復(fù)的測(cè)試,在局域網(wǎng)內(nèi)實(shí)現(xiàn)VoIP通信,丟包和誤碼率很低,UDP協(xié)議完全可以勝任。但是在互聯(lián)網(wǎng)上實(shí)現(xiàn)VoIP通信,必須解決網(wǎng)絡(luò)傳輸不可靠的問題。Windows CE也支持RTP協(xié)議,利用RTP協(xié)議可以在UDP數(shù)據(jù)包中添加時(shí)問戳和序列號(hào)等控制信息,提高網(wǎng)絡(luò)傳輸?shù)目煽啃浴2杉囊纛l數(shù)據(jù)包首先以RTP協(xié)議進(jìn)行封裝,再用 UDP協(xié)議對(duì)RTP數(shù)據(jù)包進(jìn)行封裝,最后封裝為IP數(shù)據(jù)包,經(jīng)網(wǎng)絡(luò)進(jìn)行傳輸[4]。采用UDP和RTP相結(jié)合的方案可以保證網(wǎng)絡(luò)數(shù)據(jù)傳輸可靠,同時(shí)也保證了時(shí)延不會(huì)太大。VoIP通信過程如圖2所示。
采集到的聲音傳輸?shù)骄W(wǎng)絡(luò)的其他終端上才能完成VoIP通信,可采用Socket UDP方式來實(shí)現(xiàn)。WinSock犃犘犐中函數(shù)封裝了UDP類,可以完成UDP全部操作。首先調(diào)用socket函數(shù)來創(chuàng)建數(shù)據(jù)報(bào)套接字,然后指定本地端口、遠(yuǎn)程端口和遠(yuǎn)程ⅠP地址,接著調(diào)用sendto函數(shù)和recvfrom直接發(fā)送數(shù)據(jù)和接收數(shù)據(jù)。接收數(shù)據(jù)時(shí)需要單獨(dú)創(chuàng)建線程,并通過select事件模型來檢測(cè)UDP事件,包括數(shù)據(jù)接收事件和UDP發(fā)生錯(cuò)誤事件。
圖2 VoⅠP通信過程
數(shù)據(jù)緩存區(qū)大小的設(shè)置對(duì)語(yǔ)音信號(hào)的質(zhì)量會(huì)產(chǎn)生很大的影響。錄音數(shù)據(jù)緩存和編碼緩存區(qū)的大小必須適中。
錄音緩沖區(qū)過小,生成的語(yǔ)音數(shù)據(jù)幀也就會(huì)過小,語(yǔ)音的連續(xù)性遭到破壞,同時(shí)數(shù)據(jù)分組的有效數(shù)據(jù)率也會(huì)過小,增加了網(wǎng)絡(luò)負(fù)擔(dān)[5];如果緩沖區(qū)過大,會(huì)在語(yǔ)音錄制和其他處理時(shí)造成比較大的處理時(shí)延,還有可能造成發(fā)送的數(shù)據(jù)分組過大而導(dǎo)致某協(xié)議層的數(shù)據(jù)分割與合并,形成很大的傳輸時(shí)延。所以錄音緩沖區(qū)要選擇合適的大小,必須在語(yǔ)音的連續(xù)性和時(shí)延之間進(jìn)行平衡。在工程實(shí)踐中要根據(jù)語(yǔ)音效果來確定緩存區(qū)的大小。
編碼緩存區(qū)的大小取決于錄音緩存區(qū)的大小和編碼方式,實(shí)際應(yīng)用中要根據(jù)不同的語(yǔ)音編解碼技術(shù)設(shè)計(jì)不同的緩沖區(qū)。參考文獻(xiàn)[6]中采用的編解碼算法是GSM610,參數(shù)為11.025 kHz的采樣頻率,8位單聲道方式進(jìn)行語(yǔ)音數(shù)據(jù)采集,測(cè)出不同的緩存區(qū)大小帶來的時(shí)延。結(jié)論是當(dāng)緩沖區(qū)設(shè)置為768字節(jié)時(shí)語(yǔ)音質(zhì)量比較好,而且時(shí)延也可以接受。
嵌入式網(wǎng)絡(luò)終端的VoIP技術(shù)實(shí)用價(jià)值高,市場(chǎng)潛力巨大,但語(yǔ)音質(zhì)量不高的現(xiàn)狀制約了它的發(fā)展。本文針對(duì)VoIP時(shí)延大的不足,從減小語(yǔ)音采集和播放時(shí)延、網(wǎng)絡(luò)傳輸時(shí)延和緩存區(qū)時(shí)延三方面入手提出了不同的解決方案,對(duì)在基于Windows CE的嵌入式網(wǎng)絡(luò)終端上實(shí)現(xiàn)VoIP技術(shù)具有一定的參考價(jià)值。
[1]何花,王平,施文灶,等.基于WINCE 5.0的通信軟件設(shè)計(jì)[J].電子測(cè)量技術(shù),2010,33(11):117-123.
[2]徐勛業(yè),熊中柱,王志軍.VoIP語(yǔ)音時(shí)延的分析和研究[J].光通信研究,2007(1):11-14.
[3]肖建榮,胡劍凌,張玫.基于UDP的網(wǎng)絡(luò)音頻系統(tǒng)的 研究與實(shí)現(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í)時(shí)語(yǔ)音通信技術(shù)的研究[J].網(wǎng)絡(luò)與通信,2006(5):48-49.
[6]王佇,錢新,牛大偉.以太網(wǎng)環(huán)境下實(shí)時(shí)音頻傳輸?shù)难芯縖J].中國(guó)新通信,2007(17):16-18.