QNX下實現(xiàn)VoIP語音的應(yīng)用研究

趙付軒，楊斌

（西南交通大學(xué) 信息科學(xué)與技術(shù)學(xué)院，成都 610031）

趙付軒（碩士生）、楊斌（教授），主要研究方向為單片機與嵌入式系統(tǒng)應(yīng)用。

引 言

1 嵌入式系統(tǒng)硬件設(shè)計

1.1 OMAP3530平臺簡介

如圖1所示，BeagleBoard開發(fā)板主要由OMAP3530異構(gòu)雙核處理器、MMC模塊、電源、I2C總線模塊及多通道緩沖串口（McBSP）等部件組成。系統(tǒng)由MMC模塊通過SD卡啟動Bootloader及QNX操作系統(tǒng)，通過I2C總線模塊連接語音模塊，通過McBSP連接其他模塊。

圖1 BeagleBoard開發(fā)板

OMAP3530采用一種獨特的雙核結(jié)構(gòu)，把控制性較強的ARM處理器和高性能、低功耗的DSP結(jié)合起來，是一種開放式的可編程體系結(jié)構(gòu)。對于一些運算量大的實時信號，例如圖像、音頻數(shù)據(jù)，可以采用DSP進行計算，而對于通信、外設(shè)控制等功能，則采用ARM處理器來實現(xiàn)，從而在功耗和復(fù)雜應(yīng)用之間建立了良好的平衡。利用不同的內(nèi)核（ARM和DSP）和硬件加速器的不同功能，根據(jù)性能或功耗的要求將一個算法映射到最佳的處理器引擎，這樣分別發(fā)揮了DSP和ARM核的優(yōu)勢，與傳統(tǒng)只使用ARM核或只使用DSP芯片的移動終端相比，OMAP成功實現(xiàn)了性能與功耗的最佳組合。

1.2 ARM和DSP核之間的通信

ARM與DSP通信結(jié)構(gòu)框圖如圖2所示。Codec Engine是連接ARM和DSP或協(xié)處理器的橋梁［1］，是介于應(yīng)用層（ARM側(cè)的應(yīng)用程序）和信號處理層（DSP側(cè)的算法）之間的軟件模塊。ARM應(yīng)用程序調(diào)用Codec Engine的 VISA （Video，Image，Speech，Audio）API，如圖2中VIDENC＿process（a，b，c）。Codec Engine的stub（ARM側(cè)）會把參數(shù)a、b、c以及要調(diào)用DSP側(cè)process這個信息打包，通過消息隊列（message queue）傳遞到DSP。Codec Engine的skeleton（DSP側(cè)）會解開這個參數(shù)包，把參數(shù)a、b、c轉(zhuǎn)換成DSP側(cè)對應(yīng)的參數(shù)x、y、z（比如ARM側(cè)傳遞的是虛擬地址，而DSP只能認物理地址），DSP側(cè)的server（優(yōu)先級較低，負責(zé)和ARM通信的任務(wù)）會根據(jù)process這一信息創(chuàng)建一個DSP側(cè)的process（x，y，x）任務(wù)最終實現(xiàn) VIDENC＿process（a，b，c）的操作。

圖2 ARM與DSP通信結(jié)構(gòu)框圖

1.3 語音采集和播放模塊

QSA（QNX Sound Architecture）繼承和擁有大部分0.5.2版的高級Linux聲音架構(gòu)（ALSA）的特點。雖然QNX聲音架構(gòu)（QSA）和高級Linux聲音架構(gòu)（ALSA）有很多相似的地方，但是它們并不兼容。在QNX Neutrino 6.5.0中現(xiàn)在支持兩個以上聲道，并且提供了一種機制，這種機制可以讓你配置聲音轉(zhuǎn)換器插件以增加或減少聲音或聲道［2］。QNX聲音架構(gòu)支持各種各樣的數(shù)據(jù)格式。QNX的聲音架構(gòu)分三個層次，從上層的ALSA應(yīng)用層到中間ALSA內(nèi)核及驅(qū)動層（其中包括編解碼器及平臺驅(qū)動等），再到最底層的OMAP3530的硬件層（包括I2C總線控制接口、系統(tǒng)DMA及 McBSP）。ALSA SoC架構(gòu)如圖3所示。

1.4 操作系統(tǒng)

如圖4所示，QNX是一個真正的微內(nèi)核操作系統(tǒng)［3］。在微內(nèi)核RTOS中，應(yīng)用程序、設(shè)備驅(qū)動程序、文件系統(tǒng)和網(wǎng)絡(luò)協(xié)議棧都駐留在內(nèi)核外部的獨立地址空間，它們與內(nèi)核以及彼此之間相互隔離，因此該系統(tǒng)具有出色的故障包容性，一個組件的故障不會導(dǎo)致整個系統(tǒng)崩潰。QNX是一個多任務(wù)、多用戶、分布可嵌入、符合POSIX標準的操作系統(tǒng)。QNX又是一個實時操作系統(tǒng)，它提供用戶可控制的、優(yōu)先級驅(qū)動的、基于優(yōu)先搶占的調(diào)度方式。它的自身開銷小、上下文切換快，在同樣的硬件條件下給實時應(yīng)用留下更大的余地。

圖3 ALSA SoC架構(gòu)

圖4 QNX系統(tǒng)微內(nèi)核架構(gòu)

2 VoIP技術(shù)

2.1 VoIP基本原理

通過語音的壓縮算法對語音數(shù)據(jù)編碼進行壓縮處理，然后把這些語音數(shù)據(jù)按TCP／IP標準進行打包，經(jīng)過IP網(wǎng)絡(luò)把數(shù)據(jù)包送至接收地，再把這些語音數(shù)據(jù)包串起來，經(jīng)過解壓處理后，恢復(fù)成原來的語音信號，從而達到通過網(wǎng)絡(luò)傳送語音的目的。

2.2 VoIP協(xié)議

VoIP架構(gòu)中用到的協(xié)議主要有RTP、UDP及IP，語音數(shù)據(jù)流程如圖5所示。

據(jù)自然正家的數(shù)據(jù)統(tǒng)計，在服務(wù)過程中換用公司自發(fā)研制的清潔套組后，員工的工作效率提升了17%，客戶滿意率達到98%以上。好品質(zhì)的清潔套組和高口碑的服務(wù)在客戶群中口口相傳，公司的訂單也就越來越多。

圖5 語音數(shù)據(jù)流程

采集的語音通過壓縮RTP、UDP及IP打包之后通過局域網(wǎng)進行傳輸，然后在接收端解IP包，執(zhí)行相反的過程，最后播放語音。VoIP通道實際上是語音分組、RTP和UDP的通道。它并非一個IP的通道，因為在每個節(jié)點上IP協(xié)議都被使用。

作為VoIP的設(shè)計者，必須注意緩沖區(qū)大小、分組尺寸以及分組丟失率等問題。分組丟失的越多，接收端的語音質(zhì)量就會越差；而另一方面，分組尺寸太大又會增大等待時間，并造成緩沖區(qū)的增大。

2.3 語音壓縮編解碼技術(shù)

用于VoIP中的常見的編碼器有：ITU－T G.723語音編碼器、ITU－T G.728語音編碼器、ITU－T G.729語音編碼器。語音編碼器的主要功能就是把用戶語音的PCM樣值編碼成少量的比特（幀）。語音編碼器是建立和處理VoIP分組的發(fā)動機，它由DSP驅(qū)動。

G.729原來是8kb／s的話音編碼標準［4］，現(xiàn)在的工作范圍擴展至6.4～11.8kb／s，話音質(zhì)量也在此范圍內(nèi)有一定的變化，但即使是6.4kb／s，話音質(zhì)量也還不錯，因而很適合在VoIP系統(tǒng)中使用。

3 系統(tǒng)軟件開發(fā)架構(gòu)

由于OMAP3530是ARM和DSP異構(gòu)雙核處理器，目前還沒有一個統(tǒng)一的集成開發(fā)環(huán)境，所以本設(shè)計需要采用ARM端QNX IDE和DSP端CCS IDE兩套集成開發(fā)環(huán)境。系統(tǒng)的軟件架構(gòu)如圖6所示。

圖6 系統(tǒng)軟件架構(gòu)

為了簡化軟件開發(fā)，DSP的軟件結(jié)構(gòu)從通用處理器（GPP）的編程環(huán)境中抽象出來。在OMAP軟件體系結(jié)構(gòu)中，這種抽象通過定義一個接口，使GPP成為系統(tǒng)的主控者來實現(xiàn)。該接口由一系列包括設(shè)備驅(qū)動接口的API組成，提供一種通信機制，使得GPP應(yīng)用程序能夠完成諸如初始化、控制DSP任務(wù)、與DSP交換信息、接收或發(fā)送數(shù)據(jù)流到DSP、狀態(tài)查詢等工作。通過資源管理器接口，GPP應(yīng)用程序調(diào)用DSP的功能函數(shù)，就像在本地調(diào)用一樣。這種軟件體系結(jié)構(gòu)允許開發(fā)人員在GPP的操作系統(tǒng)上使用C語言編程，而不直接面對底層硬件，并且使開發(fā)人員得以容易地使用符合標準的DSP算法，而無需深入了解DSP就可以利用DSP來加速信號處理任務(wù)，實現(xiàn)多媒體、語音或其他功能，從而充分發(fā)揮OMAP處理器的性能。

4 系統(tǒng)實現(xiàn)

4.1 語音采集和播放模塊

語音采集和播放模塊的作用是將音頻模擬信號轉(zhuǎn)換為數(shù)字信號，并對信號進行PCM編碼。QNX操作系統(tǒng)中語音采集與播放是相似的，下面介紹具體步驟。

（1）打開PCM設(shè)備

打開一個播放設(shè)備：

（2）配置PCM設(shè)備

snd＿pcm＿plugin＿info（）使用插件轉(zhuǎn)換器，如果硬件有一個自由子通道，插件轉(zhuǎn)換器可以做任何轉(zhuǎn)換；snd＿pcm＿channel＿info（）直接訪問硬件，這個函數(shù)只返回硬件的處理能力。

（3）控制語音轉(zhuǎn)換

實際的語音轉(zhuǎn)換是由snd＿pcm＿voice＿conversion結(jié)構(gòu)體控制的。

（4）準備PCM子通道

采集或播放語音流的下一步就是準備運行的已分配的子通道。

① 當(dāng)沒有用插件接口時使用snd＿pcm＿plugin＿prepare（）；

② 當(dāng)沒有準備好時，snd＿pcm＿channel＿prepare（）函數(shù)會依據(jù)指定的通道調(diào)用snd＿pcm＿capture＿prepare（）或snd＿pcm＿playback＿prepare（）。

③關(guān)閉PCM子通道，完成采集或播放語音數(shù)據(jù)時，可以通過調(diào)用snd＿pcm＿close（）關(guān)閉子通道。

一旦打開和配置了一個PCM回放設(shè)備，并且準備好了PCM子通道，就可以采集或播放語音數(shù)據(jù)了。

4.2 語音網(wǎng)絡(luò)傳輸

VoIP中網(wǎng)絡(luò)傳輸技術(shù)主要是RTP和UDP［6］。由于實時傳輸協(xié)議RTP提供具有實時特征的、端到端的數(shù)據(jù)傳輸業(yè)務(wù)，因此VoIP可用RTP來傳送話音數(shù)據(jù)。在RTP報頭中包含裝載數(shù)據(jù)的標識符、序列號、時間戳及傳送監(jiān)視等，通常RTP協(xié)議數(shù)據(jù)單元是用UDP分組來承載，而且為了盡量減少時延，話音凈荷通常都很短。IP、UDP和RTP報頭都按最小長度計算。VoIP話音分組開銷很大，采用RTP協(xié)議的VoIP格式，在這種方式中將多路話音插入話音數(shù)據(jù)段中，可以提高傳輸效率。

用較短的數(shù)據(jù)包來傳送語音業(yè)務(wù)是很重要的。如果在網(wǎng)絡(luò)中丟失了一個數(shù)據(jù)包，由于短包中包含重要語音信息的可能性較小，所以影響不大。大多數(shù)低速率語音編解碼器都只產(chǎn)生短語音數(shù)據(jù)包，一般幀長為10～30ms，數(shù)據(jù)包的長度為10～30字節(jié)，一種典型的數(shù)據(jù)包是40字節(jié)，采用短包可以使數(shù)據(jù)比特穿過輸入接口的等待時間縮短。

結(jié) 語

對于語音開發(fā)來說，QNX實時操作系統(tǒng)是一個不錯的選擇，支持較多的音頻編解碼，編程接口符合POSIX標準，可移植性較強。本設(shè)計使用基于OMAP3530處理器的BeagleBoard開發(fā)板，功能強大，可以實現(xiàn)較高的語音通話質(zhì)量。

［1］TI.Codec Engine Algorithm Creator User's Guide［OL］.（2010－03）［2012－02］.http：／／www.ti.com.

［2］QNX Audio Developer's guide［OL］.（2011－05）［2012－02］.http：／／www.qnx.com.

［3］Getting Started with QNX Neutrino：A Guide for Realtime Programmers［OL］.（2011－05）［2012－02］.http：／／www.qnx.com.

［4］ITU－T G.729reference［OL］.（2010－08）［2012－02］.http：／／www.itu.int／en／pages／default.aspx.

［5］TI.OMAP3530Datasheet［OL］.（2011－01）［2012－02］.http：／／www.ti.com／omap3530.pdf.

［6］Uyless Black.Voice over IP［OL］.（2011－06）［2012－02］.http：／／en.wikipedia.org／wiki／Voice＿over＿IP.