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