基于高速公路網(wǎng)的無線語音系統(tǒng)的設(shè)計

康維新，繆 晶

(哈爾濱工程大學 信息與通信工程學院，哈爾濱 150001)

目前，隨著中國車輛保有量的增多，高速公路里程不斷延伸.有限的維護力量與增長的公路里程的矛盾，成為了一個越來越突出的問題[1].目前前后方維修工作的信息溝通主要依賴移動電話方式，成本較高，而高速公路網(wǎng)的現(xiàn)有網(wǎng)絡(luò)資源得不到充分利用.

鑒于以上問題，本文提出了基于高速公路網(wǎng)的無線語音系統(tǒng)的設(shè)計，系統(tǒng)硬件平臺采用三星公司S3PV210作為主控單元，搭載Marvell-88w8686無線wifi硬件模塊，軟件平臺采用開源的，可移植性強的嵌入式Linux系統(tǒng)，結(jié)合了數(shù)字化音頻采集，G726音頻編解碼，RTP/RTCP流媒體協(xié)議與多線程技術(shù)，采用GTK+技術(shù)作為人機界面[2].整個系統(tǒng)模塊化設(shè)計，具有成本低廉，體積小，擴展性好，移動性強等特點，系統(tǒng)測試表明，語音辨識度高，實時性好，能夠滿足交通管理人員的要求.

1 系統(tǒng)總體方案及架構(gòu)

1.1 系統(tǒng)硬件設(shè)計

本系統(tǒng)分為服務(wù)端與客戶端2個部分，其中服務(wù)端作為一個可移動終端，在高速公路上使用，用于接收與發(fā)送語音信息，服務(wù)端采用基于Cortex-A8架構(gòu)的S3PV210作為硬件核心處理器，系統(tǒng)架構(gòu)如圖1所示.

圖1 系統(tǒng)架構(gòu)圖

服務(wù)端的硬件構(gòu)成主要有：S3CPV210 ARM處理器、WM8960聲卡、SD-WIFI模塊、FALSH、SDRAM.WM8960作為采集播放核心，該芯片內(nèi)置有麥克風接口和立體聲耳機驅(qū)動器以及立體聲24比特sigma-delta模數(shù)轉(zhuǎn)換器(ADC)和數(shù)模轉(zhuǎn)換器(DAC)，用于采集播放原始PCM音頻；SD-WIFI模塊以Marvell-88w8686為無線處理核心，用于服務(wù)端無線接入高速公路網(wǎng)絡(luò)；服務(wù)端配備4.3寸LCD觸摸屏，實現(xiàn)人機交互；FLASH用于存儲系統(tǒng)及用戶程序；SDRAM為服務(wù)端提供工作內(nèi)存服務(wù).

客戶端為PC端，滿足客戶端軟件安裝配置即可.

1.2 系統(tǒng)軟件設(shè)計

在服務(wù)端，本文選用嵌入式Linux系統(tǒng)，按功能將軟件程序分為四層:引導加載程序，系統(tǒng)內(nèi)核程序，文件系統(tǒng)程序，應(yīng)用程序如圖2所示.

圖2 軟件結(jié)構(gòu)框圖

引導加載程序主要用于開機引導嵌入式Linux系統(tǒng)的啟動、配置正確系統(tǒng)環(huán)境，本系統(tǒng)選用對處理器架構(gòu)通用性好的u-boot；嵌入式系統(tǒng)內(nèi)核選用Linux3.0.1版本內(nèi)核，文件系統(tǒng)選用能夠更好的支持大容量NAND FLASH的yaffs2文件系統(tǒng)，系統(tǒng)程序存儲在FLASH中，在SDRAM中運行；應(yīng)用程序工作在系統(tǒng)程序之上，音頻的采集播放、編解碼，wifi的連接均工作在這一層，采用ALSA數(shù)字音頻編解碼技術(shù)播放、采集PCM音頻數(shù)據(jù)，G.726編解碼PCM數(shù)據(jù)，RTP/RTCP實現(xiàn)編碼音頻數(shù)據(jù)的發(fā)送、接受.

在客戶端，采用Gtk+圖形界面技術(shù)實現(xiàn)人機的交互，實現(xiàn)與服務(wù)端的連接與音頻的設(shè)置.系統(tǒng)軟件設(shè)計框圖如圖3、4所示.

圖3 服務(wù)端軟件設(shè)計

圖4 客戶端軟件設(shè)計

2 關(guān)鍵技術(shù)實現(xiàn)

2.1 ALSA音頻采集的實現(xiàn)

ALSA(Advanced Linux Sound Architecture)，高級Linux聲音架構(gòu)的簡稱,它在Linux操作系統(tǒng)上提供了音頻和MIDI(Musical Instrument Digital Interface，音樂設(shè)備數(shù)字化接口)的支持[3].在2.6系列內(nèi)核中，ALSA已經(jīng)替換OSS(Open Sound System，開放聲音系統(tǒng))成為默認的聲音處理模塊.

ALSA首先打開采集或播放設(shè)備，為設(shè)備參數(shù)申請空間，然后設(shè)置采集播放參數(shù)，本文采集播放采樣率8 kHz，量化位數(shù)16，單聲道的PCM語音數(shù)據(jù)，最后關(guān)閉設(shè)備.音頻采集流程如圖5所示.

圖5 ALSA采集流程圖

2.2 G.726編解碼的實現(xiàn)

聲音是一種模擬信號，為了計算機可以識別處理聲音，需要進行模數(shù)轉(zhuǎn)換，并且進行PCM編碼，即脈沖調(diào)制.G.711是現(xiàn)在使用最普遍的編碼技術(shù)，它是目前全世界電路交換電話網(wǎng)中使用的編碼技術(shù).G.711使用A率或μ率PCM方法對采樣率為8 kHz的音頻數(shù)據(jù)進行編碼，壓縮后的音頻碼率為64 kbit/s.在保證聲音質(zhì)量的基礎(chǔ)上，為了進一步利用占用線路資源，還需要對語音數(shù)據(jù)進行進一步壓縮，進一步壓縮編碼的方法就是采用ADPCM，而G.726編解碼器就是采用了ADPCM算法的編解碼器[4-5].

ADPCM綜合APCM的自適應(yīng)特性和DPCM系統(tǒng)的差分特性，是一種效果比較突出的波形編碼算法.它的關(guān)鍵思想是：1)利用自適應(yīng)的想法改變量化階的大小，即使用大的量化階去編碼比較大的差值，使用小的量化階去編碼比較小的差值.2)使用上一個的樣本值預(yù)測下一個輸入樣本的值，盡量減小實際樣本值和預(yù)測值之間的誤差值.它的編碼框圖見圖6.

圖6 ADPCM編碼框圖

通常需要將信號從時間域轉(zhuǎn)換到頻域進行處理，式(1)、(2)所示:

k=0,1,…N-1

(1)

k=0,1,…N-1

(2)

PCM與ADPCM在算法上都沒有時延，因此可以應(yīng)用在語音的實時編解碼.將語音比特流轉(zhuǎn)換為24 kbit/s的數(shù)據(jù)流，降低了對網(wǎng)絡(luò)帶寬的要求，適宜網(wǎng)絡(luò)傳輸.

2.3 RTP/RTCP傳輸?shù)膶崿F(xiàn)

RTP被定義為在點對點或群播的傳輸情況下工作，建立RTP的目的是提供時間信息和實現(xiàn)流同步.RTP的通常使用建立在UDP(User Datagram Protocol，用戶數(shù)據(jù)包協(xié)議)上，但也可以在TCP(Transfer Control Protocol，傳輸控制協(xié)議)或ATM(Asynchronous Transfer Mode，異步傳輸模式)等其他協(xié)議之上工作.RTP只有依靠RTCP才能保證實時數(shù)據(jù)的傳輸，也就是說，RTCP為RTP提供按順序傳送數(shù)據(jù)包的可靠機制，還有流量控制[6-7].

實時傳輸控制協(xié)議RTCP在RTP會話期間，各參與者按時地發(fā)送RTCP包，RTCP包中含有發(fā)包數(shù)、丟包數(shù)等信息，所以，服務(wù)器可以利用這些信息隨時調(diào)節(jié)傳輸速率的大小，甚至調(diào)節(jié)有效載荷類型.RTP和RTCP互相配合使用，能以有效的控制和最小的代價使傳輸效果最大化，所以，特別適合用于音視頻等實時流的傳輸.下面分別介紹RTP與RTCP發(fā)送數(shù)據(jù)報的基本格式.

2.3.1 RTP報文格式

見圖7.

圖7 RTP報文格式

版本(V)：2 bit，RTP的版本.此協(xié)議定義的版本為2.

填充(V)：1 bit，若設(shè)置了這一位，則意味著此包在尾部需要填充多個數(shù)據(jù)位.填充的目的主要用于擴展自定義的算法，或者用于在底層的數(shù)據(jù)接收發(fā)送單元中傳輸多個RTP包.

擴展(X)：1 bit，若設(shè)置了這一位，表示在固定頭后面會擴展出一個數(shù)據(jù)頭.

CSRC計數(shù)(CC)：4 bit，CSRC計數(shù)包含了緊接在固定頭后面CSRC識別符的個數(shù).

標志(M)：1 bit，視具體協(xié)議的解釋而定.它主要用來標記數(shù)據(jù)流中重要的情況，如幀邊界.

負載類型(PT)：7 bit，設(shè)置了攜帶數(shù)據(jù)的格式，視應(yīng)用情況而定.攜帶數(shù)據(jù)的類型數(shù)字和攜帶數(shù)據(jù)的類型可以建立一種映射.其他的攜帶數(shù)據(jù)類型數(shù)字可通過非RTP的方法動態(tài)定義.

序列號(sequence number)：16 bit，序列號的初始值是隨機的.每發(fā)送一個RTP數(shù)據(jù)包，序列號的值加1，接收端根據(jù)序列號的值來確定失去的包并重新建立包的序列.

時間戳(timestamp)：32 bit，時間戳反映的是RTP數(shù)據(jù)包中第一個數(shù)據(jù)被采出來的時間，時鐘頻率依賴于攜帶數(shù)據(jù)格式的類型.

SSRC：32 bit，SSRC段標識同步源.此標識是選定的，以使同一RTP包連接中沒有兩個相同的SSRC標識的同步源.即使幾乎多個源不可能選擇同一個標識，但所有RTP實現(xiàn)都必須防止錯誤.

CSRC列表：0到15項，每項32 bit.CSRC列表表示包內(nèi)的對載荷起作用的源.標識數(shù)量由CC段給出.如超出15個作用源，也僅標識15個.CSRC標識由混合器插入列表中，采用作用源的SSRC標識.

2.3.2 RTCP包類型

SR(SenderReport)：發(fā)送者報告，當前活動發(fā)送者發(fā)送、接收統(tǒng)計.

RR(ReceiverReport)：接收者報告，非活動發(fā)送者接收統(tǒng)計.

SDES(SourceDescription)：源描述項，包括CNAME，NAME等，CNAME項的SDES包必須包含在每個組合RTCP包中[8].

BYE：表示結(jié)束.BYE作為最后一個包發(fā)送.

APP(application)：應(yīng)用特定函數(shù).

本文移植了JRTPLIB庫，通過庫函數(shù)的封裝實現(xiàn)了RTP/RTCP的工作，在設(shè)置完G.726的配置參數(shù)后，會自動間隔發(fā)送RTCP流媒體協(xié)議控制包，如圖8所示.

圖8 RTP/RTCP發(fā)送/接收流程圖

3 系統(tǒng)測試結(jié)果

在實驗室中模擬搭高速公路網(wǎng)絡(luò)環(huán)境，搭建了測試系統(tǒng)，如圖9所示，無線wifi名稱“Dlink-150”，路由速度100Mb/s.音頻質(zhì)量，算法復(fù)雜度，編解碼時延是衡量語音指標的重要幾個方面.語音基本參數(shù)如下表1所示.

表1 語音采集播放參數(shù)

從測試結(jié)果看，語音可懂度好，音頻質(zhì)量良好；算法復(fù)雜度中等，在時延方面，自身采集100 ms數(shù)據(jù)，單向編解碼時延和通信延遲約300 ms，每一個采樣點將編碼為3 bit數(shù)據(jù)，傳輸帶寬約為24 kb/s.

圖9 系統(tǒng)測試

4 結(jié) 語

本文提出了基于S3CPV210 arm硬件平臺和嵌入式Linux軟件平臺,用于高速公路信息網(wǎng)的無線語音系統(tǒng)解決方案,應(yīng)用多線程機制解決音頻同時播放、采集的問題；應(yīng)用G.726編解碼標準壓縮音頻流，降低音頻冗余與帶寬占用；應(yīng)用RTP/RTCP實時傳輸與傳輸控制協(xié)議，更利于音頻實時流在網(wǎng)絡(luò)中的傳輸，減少網(wǎng)絡(luò)時延，提高網(wǎng)絡(luò)傳輸效率；在arm服務(wù)端應(yīng)用wifi模塊，使具備移動性；移動端體積小巧，功率消耗小，在客戶端與服務(wù)端通過緩沖機制降低了語音時延.實驗表明，在理想網(wǎng)絡(luò)狀況，采樣率8 kHz，量化為數(shù)16，單聲道的情況下，時延小于0.5 s，碼率24 kbit/s，語音清晰，可懂度好.整個系統(tǒng)工作穩(wěn)定，價格適中，操作簡便，可以應(yīng)用在高速公路養(yǎng)護保養(yǎng)的通信中.

參考文獻：

[1] 劉立才, 康維新,張 強, 等. 基于高速公路信息網(wǎng)的移動嵌入式監(jiān)控系統(tǒng)設(shè)計[J]. 應(yīng)用科技, 2013, 40(3): 58-62.

[2] 宋國偉. GTK+ 2.0編程范例[M].北京: 清華大學出版社, 2002. 1-7.

[3] 羅苑棠. 嵌入式 Linux 驅(qū)動程序和系統(tǒng)開發(fā)實例精講[M]. 北京: 電子工業(yè)出版社, 2009. 234-243.

[4] 廖廣銳, 劉 萍. 基于ADPCM的語音壓縮算法研究[J]. 計算機與數(shù)字工程, 2007, 35(7): 39-41.

[5] BENVENUTO N, BERTOCCI G, DAUMER W R,etal. Report: the 32-kb/s ADPCM coding standard [J]. Bell Labs Technical Journal, 1986, 65(5): 12-22..

[6] 趙 進, 葉 梧, 馮穗力. 基于RTP/RTCP的流媒體服務(wù)器技術(shù)研究[J].中國有線電視, 2004, 1: 6-9.

[7] SEGUI F B, CEBOLLADA J C G, MAURI J L. An RTP/RTCP based approach for multimedia group and inter-stream synchronization [J]. Multimedia Tools and Applications, 2008, 40(2): 285-319.

[8] OTT J, WENGER S, SATO N,etal. Extended RTP profile for real-time transport control protocol (RTCP)-based feedback (RTP/AVPF) [J]. Request for Comments, 2006, 4585.