早期的智能小區廣播大多采用模擬方式，如調幅、調頻廣播。這種方式的優點是減少了布線的麻煩，缺點是容易在傳輸過程中受空中雜波的干擾。隨著數字技術、多媒體技術、網絡技術的發展，數字網絡音頻廣播已悄然興起。數字網絡廣播將模擬信號轉換為數字信號進行處理和傳輸。由于它采用了糾錯編碼技術，消除了模擬方式的噪聲干擾，從而保證了傳輸的可靠性。傳統廣播只能在規定的頻率和發射功率內進行傳播，覆蓋范圍受到制約。而數字網絡廣播卻可以通過網絡將廣播發送至網絡用戶，廣播范圍大幅度增大，并且其接收音質好，可令聽眾享受到CD質量的廣播節目。網絡廣播抗干擾能力強，信號幾乎零失真。目前，智能小區已開始利用千兆以太局域網進行音頻廣播。網絡廣播一般分為兩種方式：(1)下載播放，即先把數據通過網絡下載在本地，然后再用媒體播放器播放。這種廣播的優點是播放與網絡的傳輸速率無關，播放效果好，允許分段多次續傳下載，下載后可以反復播放。缺點是必須等待文件完全下載后才能播放，時間較長，且用戶端要有較大的存儲容量。(2)流式播放。流是連續傳輸的數據，流式傳輸方式是將整個多媒體文件經過特殊的壓縮方式分成一個個壓縮包，由服務器向用戶計算機連續實時傳輸。它采用邊下載邊播放的方式。與下載播放方式相比，流式播放不僅使啟動延時大幅度縮短，而且對系統緩存容量的需求也大大降低。流式播放為實時廣播提供了保證。
　　本文設計實現了一種嵌入式MP3流媒體" title="流媒體">流媒體廣播系統" title="廣播系統">廣播系統，用于智能小區的媒體廣播。系統的硬件采用嵌入式結構，優點是體積小、成本低、占有資源少、管理簡單、維護容易。因為MP3是目前網絡上音頻播放文件最普遍的格式，所以音頻數據格式采用MP3。與其他音頻數據格式(如PCM、VOC、MIDI等)相比，MP3具有較高的壓縮率和不遜于CD的音頻質量。數據傳輸和播放采用流媒體形式。采用MP3流媒體廣播的優點是兼容性強、實時性高、連續性好、數據傳輸和廣播連續進行、無須數據下載，解決了掉包、時斷時續、數據下載等待等問題。
1 嵌入式MP3流媒體網絡廣播系統的設計
　　在過去的十年中，嵌入式系統的開發與應用方式發生了很大變化，其應用已由工業、通信和網絡擴展到與數字多媒體相關的各個消費領域。過去，嵌入式系統是一個孤立的、資源有限、功能較少、用途單一的系統，各自擁有獨特的顯示方式和用戶界面。它們的生產商追求在有限的價格上滿足一定的功能要求，通常采用功能并不強大的CPU，盡可能地壓縮系統性能。今天，人們將嵌入式系統用在智能化和互聯化的系統中是希望它們能夠通過互聯網、無線或其他方式相互連接，采用相同的方式，運行很多相同的應用程序，實現多種智能化的功能。
　　由嵌入式系統的結構可以看出，在實時操作系統(RTOS)之上建立嵌入式系統的應用程序非常必要。嵌入式系統應用軟件的開發與研究，一直都是非常重要及有意義的課題。
　　本系統就是基于嵌入式Linux操作系統開發的一個應用系統，其功能是實現智能小區中MP3流媒體網絡廣播。系統主要由服務器端和客戶終端" title="客戶終端">客戶終端兩部分組成。要創建MP3流媒體廣播嵌入式系統，已有的Linux下的開放源碼工具不符合嵌入式系統的工作條件和要求(如采用icecast和ices進行創建)，因此，必須對廣播的服務器端和客戶終端進行軟件的研究和設計。本系統的服務器端在Windows環境下工作，界面用VC編程實現。嵌入式客戶終端的操作界面應用qt-embedded庫實現。
　　在小區的物業管理中心安裝了MP3廣播服務器。服務器端由管理中心人員操作。由于Windows系統的普及性及易操作性，所以在服務器端選擇以Windows作為系統平臺運行MP3的播放程序。為了讓用戶能有更多的選擇，系統實現了多路的MP3廣播。對于多路的發送與接收，主要利用RTP和RTCP所用端口號分別監聽。每一路分別采用一個獨立的RTP和RTCP端口號，與接收端的接收路數的端口號相對應。這樣才能使每一路的數據在網絡中不交叉，各自獨立。考慮到網絡的帶寬以及使用需求，本設計采用了8路通道以保證數據流能順暢地發送。在系統文件中，將需廣播的歌曲分別放置到8個不同目錄(以后對歌曲的管理都在相應的文件夾下進行)中，每路播放分別對應不同的目錄，啟動服務器端程序即啟動8路播放線程。首先分別讀出8路所對應文件夾下的所有MP3文件，每路都產生隨機數以便歌曲被隨機播放。隨后每路利用不同的RTP和RTCP端口號分別建立RTP會話。MP3數據被封裝為一個個的RTP包，不斷循環地送往小區局域網絡，直到一首歌曲發送完成，開始對下一首歌曲文件進行封包發送。這樣不斷循環，從而實現隨機循環廣播8路歌曲的目的。服務器端的結構如圖1所示。

　　在小區各用戶家中安裝系統客戶終端，客戶終端設計成通過小區局域網同時接收8路音樂廣播，并且可以對這8路音樂進行隨意選擇和切換收聽。客戶端在嵌入式環境下運行MP3廣播接收程序。用戶通過終端按鍵啟動程序，即啟動兩個線程。一個線程建立RTP會話及對8路分別會話進行相對應的設置，然后從網絡循環接收MP3數據流并將數據流寫入緩存(這里緩存采用循環隊列的概念)；另一個線程則首先對聲卡參數(如聲卡采樣率、聲道等)進行設置，然后不斷地從緩存(循環隊列)讀出MP3數據，隨后對數據流進行實時解碼并寫入聲卡，從而達到接收廣播并播放的目的。兩個線程同時進行，實現了邊從網絡接收邊播放數據的功能，體現了系統的實時性。客戶終端結構流程如圖2所示。
2 嵌入式MP3流媒體網絡廣播系統的實現
2.1 系統實現環境
2.1.1 軟件環境
　　在應用于智能小區的嵌入式MP3流媒體廣播系統的實現中，服務器端基于Windows平臺，客戶終端系統基于Linux內核。Linux操作系統可應用于多種硬件平臺，原型可以在標準平臺上開發后移植到具體的硬件上，使軟件與硬件的開發過程加快。本系統在X86上開發后再移植到硬件平臺上。Linux的高度模塊化使添加部件非常容易，而且是免費開源，定會節省大量的開發費用。Linux的優勢還體現在可靠性和軟件規模方面。Linux可以根據實際需要進行裁剪，并且具備強大的內存保護功能，可靠性高。如今，業界已經達成共識：嵌入式Linux是大勢所趨，其巨大的市場潛力與醞釀的無限商機必然會吸引眾多的廠商進入這一領域。

2.1.2 硬件環境
　　在應用于智能小區的嵌入式MP3流媒體廣播系統的實現中，嵌入式CPU采用GT2000，其CPU核心是方舟2號(Arca2)。GT2000集成了高性能CPU核心和PC架構南北橋中的大部分功能，是信息終端設備和網絡設備的理想解決方案。GT2000在400MHz主頻下運行時最大功耗只有360毫瓦，是業界最具競爭力的高性能、低功耗微處理器產品。方舟開發板Draco則為基于GT2000的產品開發提供了一個易于擴充、易于配置的平臺，本系統采用了Draco開發板。一個全新體系結構的開發與應用需要高質量編譯器工具鏈的支持。方舟CPU作為一個全新的RISC指令集體系結構，編譯器的支持至關重要。方舟科技移植增強了GNU編譯開發環境，使其對方舟CPU體系結構提供了全方位的支持。其GNU編譯工具鏈覆蓋了編譯技術和開發環境的方方面面，代碼效率及可移植性在業界處于領先地位，已成為Linux操作系統下的標準開發環境，也是嵌入式CPU開發環境事實上的工業標準。
2.2 MP3流媒體傳輸協議
　　在應用于智能小區的嵌入式MP3流媒體廣播系統的實現中，傳輸方式采用流式傳輸。實現流式傳輸的一個重要條件是要有合適的傳輸協議。RTP(Real-time Transport Protocol)正是作為這樣一種適時的傳輸協議而出現的，它是進行實時流媒體傳輸的標準協議和關鍵技術。
　　RTP協議是用于Internet上針對多媒體數據流的一種傳輸協議。RTP被定義為在一對一或一對多的傳輸情況下工作，其目的是提供時間信息和實現流同步。整個RTP協議由兩個密切相關的部分組成：RTP數據協議和RTCP控制協議。RTP 是通過在UDP上工作來進行數據傳輸的，但也可以在其他協議上(如TCP)工作。而控制協議只能使用RTCP。當應用程序開始一個RTP會話時將使用兩個端口，一個給RTP，另一個給RTCP。RTP本身并不能為按順序傳送數據包提供可靠的傳送機制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務。通常RTP算法并不作為一個獨立的網絡層來實現，而是作為應用程序代碼的一部分。RTP與RTCP配合使用，它們能以有效的反饋和最小的開銷使傳輸效率最佳化，因而特別適合傳送網上的實時數據。相對于傳統的傳輸協議，RTP協議更能保證數據的實時傳輸。
　　在本系統實現中，采用Linux下的LIVE庫進行數據傳輸。在Linux下，有很多基于RTP協議的庫，如LIBRTP、JRTPLIB、LIVE庫等。LIVE庫是一個基于RTP/RTCP/RTSP/SIP協議的流媒體傳輸庫，其移植性好，既可以在Unix平臺上編譯，也可以在Windows平臺以及其他一些系統平臺上編譯。它適合于嵌入式和低功耗場合的流媒體應用。
2.3 MP3流媒體解碼
　　在應用于智能小區的嵌入式MP3流媒體廣播系統的實現中，用戶接收端接收到的數據是網絡傳來的MP3數據流，因此，先對MP3數據流解碼，然后才能寫入聲卡播放。
　　MP3解碼過程是先將MP3數據幀解包，然后用Huffman解碼解出位分配信息。接著在逆變換中利用頻譜系數，在合成濾波器中將32個子帶合并成一個寬帶信號，18個頻譜值執行32次改進型離散余弦逆變換(IMDCT)。再將生成的576個頻譜值變換成長度為32的18個連續頻譜，通過18次運算，多相位合成濾波器將這些頻譜轉換到時域完成波形重構，生成PCM音頻數據。多相位濾波器組包含一個頻率映射運算(例如矩陣相乘)和一個有512個系數的FIR濾波器。MP3流媒體解碼的流程如圖3所示。

3 系統的試驗結果與討論
　　流式傳輸的實現需要緩存，在傳輸中實時MP3音頻文件被拆分為許多數據包。由于網絡動態變化，各個數據包選擇的傳輸路由不盡相同，所以到達客戶端時間延遲也就不等，甚至有先發的包后到及未到的情況。如果直接播放這種數據流會引起音頻的延遲和抖動，因此采用緩存系統。緩存大小的設置直接影響播放質量。本系統數據緩沖區采用了循環隊列的概念，其優點為在不斷順序讀取數據的同時又不斷將數據寫入隊列，因此使得緩沖大小相對穩定，從而保證數據的連續性。在數據發送接收的最初，由于數據量少，聲音可能出現斷續，此時，隊列數據需達到一定的數據量時才往聲卡寫入。此后往隊列不斷寫入數據并將隊列的數據不斷地寫入聲卡，從而保證了數據流的連續性。因此測試收聽音質效果好，對于每一幀的數據大小，也就是每次寫入緩沖隊列的數據，程序會根據歌曲文件的大小自動對其加以調整以最適合傳輸。例如3.3MB的文件每一幀數據被發送時大小為1 254B，而6.1MB的文件每一幀數據大小則為731B。另外，在嵌入式客戶終端操作時采用圖形界面方式。由于要照顧到不同的使用者，如老人、小孩，所以就要使操作簡單方便。本設計中只利用簡單的幾個按鍵就能直觀方便地進行操作，從而使應用操作比以往產品的復雜操作更加人性化，應用范圍更加廣泛。
　　在實驗測試中，模擬了幾種丟幀情況下的音質效果。實驗中，故意讓接收數據進入隊列時丟幀，做了幾組測試，可以觀察到丟幀概率不同時的聲音斷續情況，如表1所示。
　　從表1可以看出：丟幀率越小，斷續出現的時間間隔越大，也就是數據越流暢。而在不丟幀的情況下，亦即實驗中程序運行情況下，播放基本沒有斷續，聲音流暢、音色較好，達到了系統功能要求。