新聞中心

EEPW首頁 > 手機與無線通信 > 設(shè)計應(yīng)用 > 智能小區(qū)中嵌入式MP3流媒體網(wǎng)絡(luò)廣播系統(tǒng)設(shè)計

智能小區(qū)中嵌入式MP3流媒體網(wǎng)絡(luò)廣播系統(tǒng)設(shè)計

——
作者:鄧丹 吳小強 羅代升 時間:2007-05-11 來源:電子技術(shù)應(yīng)用 收藏
早期的智能小區(qū)廣播大多采用模擬方式.如調(diào)幅、調(diào)頻廣播。這種方式的優(yōu)點是減少了布線的麻煩,缺點是容易在傳輸過程中受空中雜波的干擾。隨著數(shù)字技術(shù)、多媒體技術(shù)、網(wǎng)絡(luò)技術(shù)的發(fā)展,數(shù)字網(wǎng)絡(luò)音頻廣播已悄然興起。

數(shù)字將模擬信號轉(zhuǎn)換為數(shù)字信號進行處理和傳輸。由于它采用了糾錯編碼技術(shù),消除了模擬方式的噪聲干擾,從而保證了傳輸?shù)目煽啃?。傳統(tǒng)廣播只能在規(guī)定的頻率和發(fā)射功率內(nèi)進行傳播,覆蓋范圍受到制約。

而數(shù)字卻可以通過網(wǎng)絡(luò)將廣播發(fā)送至網(wǎng)絡(luò)用戶,廣播范圍大幅度增大,并且其接收音質(zhì)好,可令聽眾享受到CD質(zhì)量的廣播節(jié)目。抗干擾能力強,信號幾乎零失真。目前,智能小區(qū)已開始利用千兆以太局域網(wǎng)進行音頻廣播。

網(wǎng)絡(luò)廣播一般分為兩種方式:

(1)下載播放,即先把數(shù)據(jù)通過網(wǎng)絡(luò)下載在本地,然后再用媒體播放器播放。這種廣播的優(yōu)點是播放與網(wǎng)絡(luò)的傳輸速率無關(guān),播放效果好,允許分段多次續(xù)傳下載,下載后可以反復(fù)播放。缺點是必須等待文件完全下載后才能播放,時間較長,且用戶端要有較大的存儲容量。

(2)流式播放。流是連續(xù)傳輸?shù)臄?shù)據(jù),流式傳輸方式是將整個多媒體文件經(jīng)過特殊的壓縮方式 分成一個個壓縮包,由服務(wù)器向用戶計算機連續(xù)實時傳輸。它采用邊下載邊播放的方式。與下載播放方式相比。流式播放不僅使啟動延時大幅度縮短,而且對系統(tǒng)緩存容量的需求也大大降低。流式播放為實時廣播提供了保證。
    
本文設(shè)計實現(xiàn)了一種嵌入式廣播系統(tǒng),用于智能小區(qū)的媒體廣播。系統(tǒng)的硬件采用嵌入式結(jié)構(gòu),優(yōu)點是體積小、成本低、占有資源少、管理簡單、維護容易。因為是目前網(wǎng)絡(luò)上音頻播放文件最普遍的格式,所以音頻數(shù)據(jù)格式采用。與其他音頻數(shù)據(jù)格式(如PCM、VOC、MIDI等)相比,MP3具有較高的壓縮率和不遜于CD的音頻質(zhì)量。數(shù)據(jù)傳輸和播放采用形式。采用MF3廣播的優(yōu)點是兼容性強、實時性高、連續(xù)性好、數(shù)據(jù)傳輸和廣播連續(xù)進行、無須數(shù)據(jù)下載,解決了掉包、時斷時續(xù)、數(shù)據(jù)下載等待等問題。

1 嵌入式MP3流媒體網(wǎng)絡(luò)廣播系統(tǒng)的設(shè)計
    
在過去的十年中,的開發(fā)與應(yīng)用方式發(fā)生了很大變化,其應(yīng)用已由工業(yè)、通信和網(wǎng)絡(luò)擴展到與數(shù)字多媒體相關(guān)的各個消費領(lǐng)域。過去,是一個孤立的、資源有限、功能較少、用途單一的系統(tǒng),各自擁有獨特的顯示方式和用戶界面。它們的生產(chǎn)商追求在有限的價格上滿足一定的功能要求,通常采用功能并不強大的CPU,盡可能地壓縮系統(tǒng)性能。今天,人們將用在智能化和互聯(lián)化的系統(tǒng)中是希望它們能夠通過互聯(lián)網(wǎng)、無線或其他方式相互連接,采用相同的方式.運行很多相同的應(yīng)用程序,實現(xiàn)多種智能化的功能。

由嵌入式系統(tǒng)的結(jié)構(gòu)可以看出,在實時操作系統(tǒng)(RTOS)之上建立嵌入式系統(tǒng)的應(yīng)用程序非常必要。嵌入式系統(tǒng)應(yīng)用軟件的開發(fā)與研究,一直都是非常重要及有意義的課題。

本系統(tǒng)就是基于嵌入式Linux操作系統(tǒng)開發(fā)的一個應(yīng)用系統(tǒng),其功能是實現(xiàn)智能小區(qū)中MP3流媒體網(wǎng)絡(luò)廣播。系統(tǒng)主要由服務(wù)器端和客戶終端兩部分組成。要創(chuàng)建MP3流媒體廣播嵌入式系統(tǒng),已有的Linux下的開放源碼工具不符合嵌入式系統(tǒng)的工作條件和要求(如采用icecasl和ices進行創(chuàng)建),因此,必須對廣播的服務(wù)器端和客戶終端進行軟件的研究和設(shè)計。本系統(tǒng)的服務(wù)器端在Windows環(huán)境下工作,界面用VC編程實現(xiàn)。嵌入式客戶終端的操作界面應(yīng)用qt-embedded庫實現(xiàn)。

在小區(qū)的物業(yè)管理中心安裝了MP3廣播服務(wù)器。服務(wù)器端由管理中心人員操作。由于Windows系統(tǒng)的普及性及易操作性,所以在服務(wù)器端選擇以Windows作為系統(tǒng)平臺運行MP3的播放程序。為了讓用戶能有更多的選擇,系統(tǒng)實現(xiàn)了多路的MP3廣播。對于多路的發(fā)送與接收,主要利用RTP和RTCP所用端口號分別監(jiān)聽。

每一路分別采用一個獨立的RTP和RTCP端口號,與接收端的接收路數(shù)的端口號相對應(yīng)。這樣才能使每一路的數(shù)據(jù)在網(wǎng)絡(luò)中不交叉,各自獨立??紤]到網(wǎng)絡(luò)的帶寬以及使用需求,本設(shè)計采用了8路通道以保證數(shù)據(jù)流能順暢地發(fā)送。

在系統(tǒng)文件中,將需廣播的歌曲分別放置到8個不同目錄(以后對歌曲的管理都在相應(yīng)的文件夾下進行)中,每路播放分別對應(yīng)不同的目錄,啟動服務(wù)器端程序即啟動8路播放線程。首先分別讀出8路所對應(yīng)文件夾下的所有MP3文件,每路都產(chǎn)生隨機數(shù)以便歌曲被隨機播放。

隨后每路利用不同的RTP和RTCP端口號分別建立RTP會話。MP3數(shù)據(jù)被封裝為一個個的RTP包,不斷循環(huán)地送往小區(qū)局域網(wǎng)絡(luò),直到一首歌曲發(fā)送完成,開始對下一首歌曲文件進行封包發(fā)送。這樣不斷循環(huán),從而實現(xiàn)隨機循環(huán)廣播8路歌曲的目的。服務(wù)器端的結(jié)構(gòu)如圖1所示。

服務(wù)器端的結(jié)構(gòu)

在小區(qū)各用戶家中安裝系統(tǒng)客戶終端,客戶終端設(shè)計成通過小區(qū)局域網(wǎng)同時接收8路音樂廣播,并且可以對這8路音樂進行隨意選擇和切換收聽??蛻舳嗽谇度耸江h(huán)境下運行MP3廣播接收程序。

用戶通過終端按鍵啟動程序,即啟動兩個線程。一個線程建立RTP會話及對8路分別會話進行相對應(yīng)的設(shè)置,然后從網(wǎng)絡(luò)循環(huán)接收MP3數(shù)據(jù)流并將數(shù)據(jù)流寫入緩存(這里緩存采用循環(huán)隊列的概念);另一個線程則首先對聲卡參數(shù)(如聲卡采樣率、聲道等)進行設(shè)置,然后不斷地從緩存(循環(huán)隊列)讀出MP3數(shù)據(jù),隨后對數(shù)據(jù)流進行實時解碼并寫入聲卡,從而達到接收廣播并播放的目的。兩個線程同時進行,實現(xiàn)了邊從網(wǎng)絡(luò)接收邊播放數(shù)據(jù)的功能,體現(xiàn)了系統(tǒng)的實時性。客戶終端結(jié)構(gòu)流程如圖2所示。

客戶終端結(jié)構(gòu)流程

2 嵌入式MP3流媒體網(wǎng)絡(luò)廣播系統(tǒng)的實現(xiàn)

2.1 系統(tǒng)實現(xiàn)環(huán)境

2.1.1 軟件環(huán)境
    
在應(yīng)用于智能小區(qū)的嵌入式MP3流媒體廣播系統(tǒng)的實現(xiàn)中,服務(wù)器端基于Windows平臺,客戶終端系統(tǒng)基于Linux內(nèi)核。Linux操作系統(tǒng)可應(yīng)用于多種硬件平臺,原型可以在標(biāo)準(zhǔn)平臺上開發(fā)后移植到具體的硬件上,使軟件與硬件的開發(fā)過程加快。

本系統(tǒng)在X86上開發(fā)后再移植到硬件平臺上。Linux的高度模塊化使添加部件非常容易,而且是免費開源,定會節(jié)省大量的開發(fā)費用。LJnux的優(yōu)勢還體現(xiàn)在可靠性和軟件規(guī)模方面。Linux可以根據(jù)實際需要進行裁剪,并且具備強大的內(nèi)存保護功能,可靠性高。如今,業(yè)界已經(jīng)達成共識:嵌入式Linux是大勢所趨,其巨大的市場潛力與醞釀的無限商機必然會吸引眾多的廠商進入這一領(lǐng)域。

2.1.2 硬件環(huán)境
    
在應(yīng)用于智能小區(qū)的嵌入式MP3流媒體廣播系統(tǒng)的實現(xiàn)中,嵌入式CPU采用GT2000,其CPU核心是方舟2號(Area2)。GT2000集成了高性能CPU核心和PC架構(gòu)南北橋中的大部分功能,是信息終端設(shè)備和網(wǎng)絡(luò)設(shè)備的理想解決方案。CT2000在40OMHz主頻下運行時最大功耗只有360毫瓦,是業(yè)界最具競爭力的高性能、低功耗微處理器產(chǎn)品。

方舟開發(fā)板Draco則為基于GT2000的產(chǎn)品開發(fā)提供了一個易于擴充、易于配置的平臺,本系統(tǒng)采用了Draco開發(fā)板。一個全新體系結(jié)構(gòu)的開發(fā)與應(yīng)用需要高質(zhì)量編譯器工具鏈的支持。方舟CPU作為一個全新的RISC指令集體系結(jié)構(gòu),編譯器的支持至關(guān)重要。

方舟科技移植增強了GNU編譯開發(fā)環(huán)境,使其對方舟CPU體系結(jié)構(gòu)提供了全方位的支持。其GNU編譯工具鏈覆蓋了編譯技術(shù)和開發(fā)環(huán)境的方方面面,代碼效率及可移植性在業(yè)界處于領(lǐng)先地位,已成為Linux操作系統(tǒng)下的標(biāo)準(zhǔn)開發(fā)環(huán)境,也是嵌人式CPU開發(fā)環(huán)境事實上的工業(yè)標(biāo)準(zhǔn)。

2.2 MP3流媒體傳輸協(xié)議
   
在應(yīng)用于智能小區(qū)的嵌入式MP3流媒體廣播系統(tǒng)的實現(xiàn)中,傳輸方式采用流式傳輸。實現(xiàn)流式傳輸?shù)囊粋€重要條件是要有合適的傳輸協(xié)議。RTP(Real-timeTransport Protocol)正是作為這樣一種適時的傳輸協(xié)議而出現(xiàn)的,它是進行實時流媒體傳輸?shù)臉?biāo)準(zhǔn)協(xié)議和關(guān)鍵技術(shù)。

TRP協(xié)議是用于Intemet上針對多媒體數(shù)據(jù)流的一種傳輸協(xié)議。RTP被定義為在一對一或一對多的傳輸情況下工作,其目的是提供時間信息和實現(xiàn)流同步。整個RTP協(xié)議由兩個密切相關(guān)的部分組成:RTP數(shù)據(jù)協(xié)議和RTCP控制協(xié)議。RTP是通過在UDP上工作來進行數(shù)據(jù)傳轄的,但也可以在其他協(xié)議上(如TCP)工作。而控制協(xié)議只能使用RTCP。

應(yīng)用程序開始一個RTP會話時將使用兩個端口,一個給RTP,另一個給RTCP。TRP本身并不能為按順序傳送數(shù)據(jù)包提供可靠的傳送機制,也不提供流量控制或擁塞控制,它依靠RTCP提供這些服務(wù)。通常RTP算法并不作為一個獨立的網(wǎng)絡(luò)層來實現(xiàn),而是作為應(yīng)用程序代碼的一部分。RTP與RTCP配合使用,它們能以有效的反饋和最小的開銷使傳輸效率最佳化,因而特別適合傳送網(wǎng)上的實時數(shù)據(jù)。相對于傳統(tǒng)的傳輸協(xié)議,RTP協(xié)議更能保證數(shù)據(jù)的實時傳輸。

在本系統(tǒng)實現(xiàn)中,采用Linux下的LIVE庫進行數(shù)據(jù)傳輸。在Linux下,有很多基于RTP協(xié)議的庫,如LIBRTP,JRTPLIB、LIVE庫等。LIVE庫是一個基于RTP/RTCP/RTSP/STP協(xié)議的流媒體傳輸庫,其移植性好,既可以在Unix平臺上編譯,也可以在Windows平臺以及其他一些系統(tǒng)平臺上編譯。它適合于嵌入式和低功耗場合的流媒體應(yīng)用。

2.3 MP3流媒體解碼
   
在應(yīng)用于智能小區(qū)的嵌入式MP3流媒體廣播系統(tǒng)的實現(xiàn)中,用戶接收端接收到的數(shù)據(jù)是網(wǎng)絡(luò)傳來的MP3數(shù)據(jù)流,因此,先對MP3數(shù)據(jù)流解碼,然后才能寫入聲卡播放。

MP3解碼過程是先將MP3數(shù)據(jù)幀解包,然后用Huffman解碼解出位分配信息。接著在逆變換中利用頻譜系數(shù),在合成濾波器中將32個子帶合并成一個寬帶信號,18個頻譜值執(zhí)行32次改進型離散余弦逆變換(IMDCT)。再將生成的576個頻譜值變換成長度為32的18個連續(xù)頻譜,通過18次運算,多相位合成濾波器將這些頻譜轉(zhuǎn)換到時域完成波形重構(gòu),生成PCM音頻數(shù)據(jù)。多相位濾波器組包含一個頻率映射運算(例如矩陣相乘)和一個有512個系數(shù)的FIR濾波器。MP3流媒體解碼的流程如圖3所示。

MP3流媒體解碼的流程

3 系統(tǒng)的試驗結(jié)果與討論
    
流式傳輸?shù)膶崿F(xiàn)需要緩存,在傳輸中實時MP3音頻文件被拆分為許多數(shù)據(jù)包。由于網(wǎng)絡(luò)動態(tài)變化,各個數(shù)據(jù)包選擇的傳輸路由不盡相同,所以到達客戶端時間延遲也就不等,甚至有先發(fā)的包后到及未到的情況。如果直接播放這種數(shù)據(jù)流會引起音頻的延遲和抖動,因此采用緩存系統(tǒng)。緩存大小的設(shè)置直接影響播放質(zhì)量。

本系統(tǒng)數(shù)據(jù)緩沖區(qū)采用了循環(huán)隊列的概念,其優(yōu)點為在不斷順序讀取數(shù)據(jù)的同時又不斷將數(shù)據(jù)寫入隊列,因此使得緩沖大小相對穩(wěn)定,從而保證數(shù)據(jù)的連續(xù)性。在數(shù)據(jù)發(fā)送接收的最初,由于數(shù)據(jù)量少,聲音可能出現(xiàn)斷續(xù),此時,隊列數(shù)據(jù)需達到一定的數(shù)據(jù)量時才往聲卡寫入。此后往隊列不斷寫入數(shù)據(jù)并將隊列的數(shù)據(jù)不斷地寫入聲卡,從而保證了數(shù)據(jù)流的連續(xù)性。因此測試收聽音質(zhì)效果好,對于每一幀的數(shù)據(jù)大小,也就是每次寫入緩沖隊列的數(shù)據(jù),程序會根據(jù)歌曲文件的大小自動對其加以調(diào)整以最適合傳輸。

例如3.3MB的文件每一幀數(shù)據(jù)被發(fā)送時大小為l254B,而6.1MB的文件每一幀數(shù)據(jù)大小則為731B。另外,在嵌入式客戶終端操作時采用圖形界面方式。由于要照顧到不同的使用者,如老人、小孩,所以就要使操作簡單方便。本設(shè)計中只利用簡單的幾個按鍵就能直觀方便地進行操作,從而使應(yīng)用操作比以往產(chǎn)品的復(fù)雜操作更加人性化,應(yīng)用范圍更加廣泛。

在實驗測試中。模擬了幾種丟幀情況下的音質(zhì)效果。實驗中,故意讓接收數(shù)據(jù)進入隊列時丟幀,做了幾組測試,可以觀察到丟幀概率不同時的聲音斷續(xù)情況,如表l所示。

丟幀情況模擬表

從表l可以看出:丟幀率越小,斷續(xù)出現(xiàn)的時間間隔越大,也就是數(shù)據(jù)越流暢。而在不丟幀的情況下,亦即實驗中程序運行情況下,播放基本沒有斷續(xù),聲音流暢、音色較好,達到了系統(tǒng)功能要求。

從系統(tǒng)實現(xiàn)及實現(xiàn)結(jié)果看,系統(tǒng)達到了工程設(shè)計要求。在發(fā)送MP3數(shù)據(jù)流時,可以同時發(fā)送多路數(shù)據(jù),在接收MP3廣播時,能順利切換各個頻道,并且音質(zhì)流暢,達到了較好接收MP3數(shù)據(jù)流的效果。系統(tǒng)操作簡單,適應(yīng)于各種層次的用戶。本系統(tǒng)除了能很好地適用于智能小區(qū)外,還可應(yīng)用于其他一些局域網(wǎng)的場合,如校園、酒店等。系統(tǒng)具有成本低、體積小、對MP3數(shù)據(jù)流可進行實時解碼等優(yōu)點,將會被越來越多地應(yīng)用于人們的生活中。



評論


相關(guān)推薦

技術(shù)專區(qū)

關(guān)閉