基于Windows CE的嵌入式網(wǎng)絡(luò)收音機(jī)
加入技術(shù)交流群
2. 3 應(yīng)用程序開發(fā)
Windows CE應(yīng)用程序使用Embedded Visual C++集成開發(fā)環(huán)境，并且需要具體平臺(tái)的SDK支持。本系統(tǒng)利用Platform Builder定制生成的SDK直接進(jìn)行開發(fā)，有效地提高了開發(fā)效率。目前，主要流媒體協(xié)議分為支持實(shí)時(shí)流式傳輸?shù)腞TSP協(xié)議和支持順序流式傳輸?shù)?MMS協(xié)議。如rtsp：／／real．enr．cn：554／encoder／cnr2(中央人民廣播電臺(tái)2臺(tái))的地址格式，這類網(wǎng)絡(luò)數(shù)字廣播采用 RTSP協(xié)議來進(jìn)行數(shù)據(jù)傳輸；如mms：／／windows_media_server／sample．a(chǎn)sf的地址格式，這類網(wǎng)絡(luò)數(shù)字廣播采用MMS協(xié)議來進(jìn)行數(shù)據(jù)傳輸。
為了盡可能接收到所有網(wǎng)絡(luò)電臺(tái)，系統(tǒng)設(shè)計(jì)兼容兩種傳輸協(xié)議。針對(duì)系統(tǒng)的特殊性，適用于該方案的系統(tǒng)設(shè)計(jì)框圖如圖3所示。系統(tǒng)通過
解析用戶輸入的網(wǎng)絡(luò)電臺(tái)網(wǎng)址，分辨出所訪問電臺(tái)支持的流媒體傳輸協(xié)議，針對(duì)兩類不同協(xié)議作出實(shí)時(shí)響應(yīng)，接收數(shù)據(jù)并播放。
2．3．1 實(shí)時(shí)流式傳輸RTSP協(xié)議
實(shí)時(shí)流協(xié)議RTSP，用于建立和控制時(shí)間同步的連續(xù)媒體流，以及控制具有實(shí)時(shí)特征的數(shù)據(jù)發(fā)送。RTSP提供控制機(jī)制，能夠處理更高層的問題(例如會(huì)話建立和注冊(cè))，在體系結(jié)構(gòu)上工作在RTP、TCP、UDP等協(xié)議的上層。正因?yàn)槿绱?，RTSP可以很好地利用人們對(duì)現(xiàn)有工業(yè)標(biāo)準(zhǔn)的改善和提高，而不需要額外的優(yōu)化工作。
本系統(tǒng)采用開源軟件LIVE庫(kù)來實(shí)現(xiàn)RTP／RTCP協(xié)議，包括RTP／RTCP會(huì)話的建立、數(shù)據(jù)的接收。其主要任務(wù)是解析RTSP協(xié)議，通過 DESCRI-BE、SETUP、PLAY請(qǐng)求來獲得音頻數(shù)據(jù)格式，并將RTP包解包獲得MP3幀數(shù)據(jù)，寫入數(shù)據(jù)接收緩沖區(qū)。
LIVE庫(kù)僅包含4個(gè)基本的類：BasicUsageEnvironment、UsageEnvironment、groupsock以及 livemedia。BasicUsageEnvironment和UsageEnvironment負(fù)責(zé)任務(wù)的調(diào)度和環(huán)境的配置；groupsock負(fù)責(zé)socks套接字的創(chuàng)建以及相應(yīng)信息(詢問信息和數(shù)據(jù)信息)的發(fā)送接收；Live-
media是整個(gè)工程的核心，負(fù)責(zé)rtsp、session(subsession)和rtcpinstance的運(yùn)轉(zhuǎn)。
在數(shù)據(jù)傳輸過程中，LIVE庫(kù)根據(jù)RTSP協(xié)議來建立會(huì)話描述。RTSP會(huì)話的建立分為以下幾個(gè)步驟：
①建立使用環(huán)境對(duì)象，創(chuàng)建客戶端。
②由RTSPClient對(duì)象向服務(wù)器發(fā)送OPTION消息并接收回應(yīng)。
③發(fā)送DESCRIBE請(qǐng)求，并解析回應(yīng)。
④根據(jù)SDPDescription在MediaSession中創(chuàng)建MediaSession對(duì)象。
⑤配置所有子會(huì)話對(duì)象。
⑥由RTSPClient對(duì)象向服務(wù)器發(fā)送SETUP消息并接收回應(yīng)。
⑦由RTSPClient對(duì)象向服務(wù)器發(fā)送PLAY消息并接收回應(yīng)。
接收到的經(jīng)過壓縮編碼的MP3音頻數(shù)據(jù)只有經(jīng)過解碼后發(fā)送給音頻設(shè)備，才能實(shí)現(xiàn)解碼播放。為了縮短開發(fā)周期，本文使用LIBMAD庫(kù)來實(shí)現(xiàn)MP3解碼。LIBMAD庫(kù)是一個(gè)開源的高精度MPEG音頻解碼庫(kù)，支持MPEG-Layer I、MPEG-Layer II和MPEG-Layer III。LIBMAD提供24位的PCM輸出，完全是定點(diǎn)計(jì)算，非常適合應(yīng)用在沒有浮點(diǎn)支持的平臺(tái)上。使用LIBMAD提供的一系列API(應(yīng)用程序編程接口)，就可以非常簡(jiǎn)單地實(shí)現(xiàn)MP3數(shù)據(jù)解碼。
為了使系統(tǒng)接收到的音頻流數(shù)據(jù)能夠正常解碼并播放，系統(tǒng)采用雙線程(數(shù)據(jù)接收線程和音樂播放線程)、雙緩沖(數(shù)據(jù)接收緩沖和音樂播放緩沖)操作。兩個(gè)線程并發(fā)運(yùn)行，且音樂播放線程運(yùn)行速度較慢。如果網(wǎng)絡(luò)速度較快，數(shù)據(jù)接收線程的接收緩沖區(qū)已滿，而當(dāng)前音樂播放線
程正在播放音樂，那么數(shù)據(jù)接收線程必須停止接收數(shù)據(jù)。如果不讓數(shù)據(jù)接收線程進(jìn)入等待狀態(tài)，它會(huì)一直輪詢音樂播放線程觀察其是否需要數(shù)據(jù)。簡(jiǎn)單的輪詢會(huì)浪費(fèi) CPU資源，在這種情況下，有必要讓數(shù)據(jù)接收線程進(jìn)入等待狀態(tài)。本系統(tǒng)使用信號(hào)量機(jī)制來動(dòng)態(tài)控制線程的運(yùn)行，有效地提高程序執(zhí)行效率。 linux操作系統(tǒng)文章專題:linux操作系統(tǒng)詳解（linux不再難懂）
評(píng)論