【導(dǎo)讀】斷涌現(xiàn)和更新,其中的背景音樂等廣播系統(tǒng)變得愈來愈必不可少。但傳統(tǒng)廣播存在信號衰。減、噪音、布線缺乏靈活性、智能程度差等問題。絡(luò)數(shù)字音頻廣播系統(tǒng)的方案和協(xié)議標(biāo)準(zhǔn)進(jìn)行了探討。制原理，對數(shù)字音頻點播和廣播系統(tǒng)的實現(xiàn)作了詳細(xì)的描述。保證實時的方法，并提出在UDP協(xié)議基礎(chǔ)上采用RTP/RTCP協(xié)議的思路。本設(shè)計（論文）題目來源于教師的企業(yè)委托科研項目，項目編號為：企2020006。

　　

【正文】 可分為私人與公有模板資源 。 與客戶端交互并完成文件服務(wù)器與數(shù)據(jù)庫服務(wù)器中內(nèi)容的配置的工作是應(yīng)用服務(wù)器，它是服務(wù)器端與客戶端之間的接口，以客戶端IP 地址作為操作單位進(jìn)行交互，遵守 TCP/IP 協(xié)議傳輸數(shù)字音頻流 。 語音 數(shù) 據(jù)流走向如下圖所示： 圖 語音數(shù)據(jù)流走向 服務(wù)器端設(shè)計 系統(tǒng)采用 c/s 模式，其中服務(wù)器端開發(fā)平臺選擇 Delphi 與 SQL2020 相結(jié)合，以數(shù)據(jù)庫與網(wǎng)絡(luò)設(shè)計為主體數(shù)據(jù)庫連接主要采用 ADO 方式進(jìn)行連接 。 點播與廣播工作都是通過服務(wù)器在數(shù)據(jù)庫內(nèi)尋找合適的音頻資源并加以編輯通過網(wǎng)絡(luò)輸送給客戶端完成的，其中點播是客戶端向服務(wù)器端主動發(fā)送請求信息的過程，而廣播是客戶端被動接收服務(wù)器端發(fā)送音頻的過程，不論是服務(wù)器端還是客戶端在同一時刻都可能面臨多 個音頻播放任務(wù)以及其它的網(wǎng)絡(luò)傳輸，因此在系統(tǒng)實現(xiàn)中一個非常重要的部分就是如何保證播放任務(wù)正確完成以及音頻傳輸?shù)臅惩ǎO(shè)計中采用通道 (Pipe)結(jié)構(gòu)表示一個完整的應(yīng)用傳輸過程，包括目的地址、傳輸碼流、音量高低、播放優(yōu)先級等傳輸控制信息 。 網(wǎng)絡(luò)中針對每一個音頻信號源，通過協(xié)議編碼形成的網(wǎng)絡(luò)信號流，流根據(jù)應(yīng)用需要，依次進(jìn)入通道，并在通道中傳輸 。 客戶端可以同時連接多個通道，根據(jù)應(yīng)用需要對不同通道中的數(shù)據(jù)流進(jìn)行混音或暫停等操作 。 下 圖 為服務(wù)器部分在點播狀態(tài)下通道連接的主要 流程圖 ： 原始語音 麥克風(fēng) 聲 卡 音頻 文件 編碼 模塊 流格式發(fā)布模塊 流格式 輸出 模擬信號 數(shù)字信號 21 圖 服務(wù)器在點播狀態(tài)下通道連接流程圖 服務(wù)器在進(jìn)行廣播時需要考慮播放區(qū)域的設(shè)置，播放時間的設(shè)定以及播放優(yōu)先級別的設(shè)定 。 系統(tǒng)管理員可以事先設(shè)置廣播分組或者通過單點選擇臨時組織廣播分組 。 同一廣播分組內(nèi)的客戶端播放同一音頻資源， 兩種方式流程圖如下： 圖 流程圖 服務(wù)器端以軟件實現(xiàn)為主，主要保證以上所述的數(shù)據(jù)庫連接與網(wǎng)絡(luò)傳輸 。 客戶端設(shè)計 客戶端是客戶直接使用系統(tǒng)的接口，分為音頻資源編輯和音頻播放兩部分 。 音頻播放系統(tǒng) 是在充足并編輯合理的音頻資源上實現(xiàn)的，因此在系統(tǒng)實現(xiàn)初期需要對播放內(nèi)容查詢指定 編號的客戶端的 IP 地址 分配通道資源，并且將新通道注冊到服務(wù)器列表中 將此客戶端設(shè)置為通道的唯一接收終端 開始運(yùn)行指定通道 按照事先設(shè)置分組進(jìn)行廣播 如果某一分組被選擇 在數(shù)據(jù)庫內(nèi)查詢該組內(nèi)所有客戶端 IP 地址 將該組內(nèi)所有當(dāng)前在線客戶端添加到播放通道中 臨時組成分組 循環(huán)所有可以選擇的客戶端 如果該客戶端被選擇并在線，則將該客戶端 IP 地址加入廣播通道 在完成對廣播分組的設(shè) 置后，使用當(dāng)前廣播通道進(jìn)行廣播 循環(huán)所有己存在的分組 22 進(jìn)行調(diào)查和收集，根據(jù)客戶需求或者與客戶合作編輯音頻資源，制作節(jié)目表和節(jié)目模板資源，流程圖如 下 所示 : 圖 節(jié)目編輯流程 圖 根據(jù)以上流程，首先利用音頻處理軟件對現(xiàn)有的模擬音頻信號 (如錄音帶上的音頻內(nèi)容 )進(jìn)行采集、編輯制作，并對本底噪音較大的內(nèi)容進(jìn)行降噪處理，制作成 MP3 格式的數(shù)字音頻信號 。 然后編輯節(jié)目模板，根據(jù)播放的需求，在音頻資源庫中選取所需的音頻素材，根據(jù)播放需求將素材進(jìn)行劃 分與編輯，最后課件模板信息存入節(jié)目模板數(shù)據(jù)庫 ，最后編排節(jié)目表，系統(tǒng)管理人員根據(jù)需求，將播出時間、播出地點 (客戶端播放 IP 地址 )設(shè)定成唯一對應(yīng)關(guān)系，再與己經(jīng)編輯好的音頻模板結(jié)合，生成節(jié)目表 。 音頻播出客戶端是以嵌入式音頻盒為主，內(nèi)置板卡固化了與服務(wù)器端相似的網(wǎng)絡(luò)連接、發(fā)送指令、接收及播放音頻流代碼，使用者只需要使用遙控器便可以通過網(wǎng)絡(luò)方便的播放音頻 。 客戶端向服務(wù)器端發(fā)送請求和接收指令是采用 WinSock 程序設(shè)計，利用Delphi 里的 IdTCPClient 和 IdTCPServer 控件 實現(xiàn)建立 TCP/IP 連接， 當(dāng)客戶端發(fā)送播放請求的指令給服務(wù)器端后，通過 SQL 語句在數(shù)據(jù)庫中查詢到請求的音頻文件，然后利用通道將音頻流發(fā)送到客戶端播出，系統(tǒng)設(shè)計的時候自定義了客戶端與服務(wù)端的通訊協(xié)議 。 基礎(chǔ)信息建立 節(jié)目表編排 節(jié)目表微調(diào) 廣播 節(jié)目模板生成 節(jié)目表調(diào)整 音頻資源轉(zhuǎn)換及生成 點播 23 4 協(xié)議的研究 以太網(wǎng)協(xié)議 一個標(biāo)準(zhǔn)的以太網(wǎng)物理傳輸幀由 7部分組成 (如 下 表所示，單位 :B)。 表 41 以太網(wǎng)的物理傳輸幀結(jié)構(gòu)表 PR SD DA SA TYPE DATA FCS 同步位 分隔位 目的地址 源地址 類型字段 數(shù)據(jù)段 幀校驗序 7 1 6 6 2 46~1500 4 除了數(shù)據(jù)段的長度不定外，其它部 分的長度固定不變 ， 數(shù)據(jù)段為 46～ 1500B。以太網(wǎng)規(guī)定整個傳輸包的最大長度不能超過 1514B(14B為 DA、 SA和 TYPE)，最小不能小于60B。除去 DA、 SA和 TYPE的 14B，還必須傳輸 46B的數(shù)據(jù)，當(dāng)數(shù)據(jù)段的數(shù)據(jù)不足 46B時需填充，填充字符的個數(shù)不包括在長度字段里；超過 1500B時，需拆成多個幀傳送。事實上，發(fā)送數(shù)據(jù)時， PR、 SD、 FCS及填充字段這幾個數(shù)據(jù)段由以太網(wǎng)控制器自動產(chǎn)生；而接收數(shù)據(jù)時， PR和 SD被跳過，控制器一旦檢測到有效的前序字段 (即 PR和 SD)，就認(rèn)為接收數(shù)據(jù)開始。 時鐘同步 的 必要性及其 算法 的研究 在實時音頻傳輸網(wǎng)絡(luò)作為一個分布式系統(tǒng)中含有大量的節(jié)點，每個節(jié)點又運(yùn)行著不確定數(shù)目的模塊。這些節(jié)點，模塊需要同步，按照一定的順序和時間要求，聯(lián)合起來完成一個具體的任務(wù)。某些模塊之間的執(zhí)行順序出現(xiàn)差錯或截止期出現(xiàn)錯誤將會使系統(tǒng)產(chǎn)生錯誤甚至帶來嚴(yán)重的后果。但是，由于很多模塊都是獨立地運(yùn)行在不同的處理機(jī)上，它們所作出的決定依賴于本地可用信息，而處理機(jī)由于型號，生產(chǎn)廠家，主頻頻率以及相互之間的通信而造成各自的參考時間不一致，甚至出現(xiàn)大的偏差 [11]。 所以在實時分布式系統(tǒng)中，尤其是在實時音頻傳 輸網(wǎng)絡(luò)這種用來傳播具有時間先后邏輯的音頻數(shù)據(jù)的系統(tǒng)中， 保持內(nèi)部時鐘同步是保證實時系統(tǒng)邏輯正確的關(guān)鍵，為此采用了一種稱為 NMessage的時鐘同步算法 [12]。 設(shè)有一標(biāo)準(zhǔn)時鐘 tc，每隔一個固定的時間間隔 I對各個節(jié)點進(jìn)行一次時間同步。 i開始進(jìn)行時鐘同步的時間是 tci ,下一次開始的時刻為 tci+I，一般的 cjci tt ? ，見 下圖 所示。 24 圖 時鐘同步周期 N— Message算法 的解決方法是：采用 N次采樣求樣本平均值， 節(jié)點開始進(jìn)行時鐘同步時，對其它每個節(jié)點發(fā)送 N個同步請求，從而得到 N個響應(yīng)數(shù)據(jù)包。其具體描述是：將同步請求數(shù)據(jù)包打上時間戳標(biāo)記0at，向其它節(jié)點廣播同步請求，共廣播 N次。 ① 收集其它節(jié)點返回的同步請求應(yīng)答數(shù)據(jù)包 jrP ，并打上時間戳標(biāo)記1at，該響應(yīng)數(shù)據(jù)包有 N個。 ② 對于所有的 j且 j≠ i，計算節(jié)點 i與 j的時間偏差 ijF ， 0 1 0 11 1 ,1 = [ ( ) ( ) ]2 NK j j j jij a a b bk j j iF t t t tn ? ? ? ? ? ??? () 計算節(jié)點 i的時鐘與新的同步目標(biāo)時間的偏差 i 和新的時鐘頻率 nR ， 1,1 N ijj j iiFn ??? ? () 0(1 / ) /nR i I R?? () ③根據(jù)計算所得的 i 和 nR 重新設(shè)定 RT Clock和計時器的初值。 UDP 音頻數(shù)據(jù)發(fā)送的實現(xiàn) UDP 傳輸時網(wǎng)絡(luò)數(shù)據(jù)包的傳送質(zhì)量（傳送延時 、 擁塞 、 丟包）是動態(tài)變化的，尤其是擁塞和丟包，而且對數(shù)據(jù)的實時擁塞操作并不容易。 盡管 UDP 協(xié)議延時較小，但 在不可靠網(wǎng)絡(luò)條件下，這仍然是影響傳輸?shù)闹匾蛩亍Ｔ诨?UDP 協(xié)議的實時應(yīng)用中，通常在客戶端設(shè)定一個緩沖器來減少網(wǎng)絡(luò)的延時。接收到的數(shù)據(jù)包先壓入緩沖器，當(dāng)緩?fù)竭M(jìn)程工作 同步進(jìn)程工作 同步進(jìn)程工作 同步進(jìn)程工作 ttc ?? Itcj?ct ttItci? 25 沖器中達(dá)到預(yù)定數(shù)量的包后，開始解碼播放。 這樣可以減少延時變化的影響，這種緩沖器稱為 Playout Buffer（簡稱 PB），它的大小應(yīng)該是隨著網(wǎng)絡(luò)的變化而變化的。選定PB 的大小至關(guān)重要，因為如果 PB 過小，一些最終能到達(dá)甚至馬上就要到達(dá)的數(shù)據(jù)包可能會被認(rèn)為丟包而遺棄，增大了丟包的可能性。相反，如果 PB 設(shè)定過大，將有更大延時，而延時的過大將有可能超過人耳能夠 覺察的門限值 [13]。 由網(wǎng)絡(luò)參數(shù)確定 PB 緩沖器的大小在參考文獻(xiàn)中有詳細(xì)論述， 參考文獻(xiàn) [14]介紹了基于網(wǎng)絡(luò)參數(shù)的自適應(yīng) PB 算法 。 該系統(tǒng)數(shù)據(jù)的 UDP 傳輸采用 VC++ 實現(xiàn) ,運(yùn)用 Windows Sockets 實現(xiàn) UDP 協(xié)議的數(shù)據(jù)傳輸 。 Windows Sockets 規(guī)范定義了如何使用 API 與 Inter 協(xié)議族 (IPS,通常是指 TCP/IP或 UDP/IP)的連接 ,支持流套接字 (Socket)和數(shù)據(jù)報套接字。流套接字提供了雙向的、有序的、無重復(fù)并且無記錄邊界的數(shù)據(jù)流服務(wù)，即實現(xiàn)了 TCP 協(xié)議的數(shù)據(jù)傳輸， 在 FTP及遠(yuǎn)程登陸（ Tel）等領(lǐng)域運(yùn)用廣泛 ； 數(shù)據(jù)報套接字支持雙向的數(shù)據(jù)流，但并不保證是可靠、有序、確認(rèn)和無重復(fù)的，它實現(xiàn)的是 UDP 協(xié)議的數(shù)據(jù)傳輸 。 應(yīng)用程序調(diào)用Windows Sockets 的 API 實現(xiàn)通信 。 Windows Sockets 完全封裝了 UDP 協(xié)議 ， 只要調(diào)用Sockets 的相應(yīng)函數(shù)就能建立一個套接字 ， 并與對應(yīng)的套接字通信 ， 實現(xiàn) UDP 數(shù)據(jù)的實時傳輸 。 以太網(wǎng)數(shù)據(jù)包的優(yōu)先級 以太網(wǎng)用于實時傳輸另一個不足在于以太網(wǎng)沒有數(shù)據(jù)包的優(yōu)先級概念 [15]。任何數(shù)據(jù)包都是一樣的，在以太網(wǎng)中不存在哪個優(yōu)先級 高哪個優(yōu)先級低的概念。這樣對于某些實時數(shù)據(jù)而言，在以太網(wǎng)中它們將不得不等待其它非實時數(shù)據(jù)傳輸完成后才能進(jìn)行傳輸。 根據(jù)實時性要求把數(shù)據(jù)包分成兩部分，把實時性要求高的數(shù)據(jù)包放在隊列前面 ； 按數(shù)據(jù)包的效用截止期比，分別把實時性要求高的數(shù)據(jù)包和實時性要求低的數(shù)據(jù)包按效用截止期比值做降序排列，即以數(shù)據(jù)包的效用截至期比來確定數(shù)據(jù)包的優(yōu)先級，優(yōu)先級高表明它效用截止期比較大，也就應(yīng)該越早發(fā)送 。在隊列執(zhí)行過程中，比較每個將要發(fā)送的數(shù)據(jù)包的發(fā)送時間和剩余截止期，跳過不可能在截止期前及時發(fā)送的數(shù)據(jù)包。把目的地址和源地址相同的數(shù)據(jù) 包看作是一組數(shù)據(jù)包，如果這組數(shù)據(jù)包的發(fā)送失敗次數(shù)到達(dá)一定程度，就應(yīng)該提升它的效用截止期比。這樣就可以避免某兩個節(jié)點之間通訊被堵塞的情況。 26 傳輸協(xié)議模式 以太網(wǎng)對媒質(zhì)訪問的控制是通過一種稱為 CSMA/CD的協(xié)議來實現(xiàn)的。當(dāng)一個節(jié)點試圖發(fā)送數(shù)據(jù)時，它首先偵聽以太網(wǎng)總線，如果還有其它節(jié)點在發(fā)送數(shù)據(jù)，那么它一直等到總線空閑時再發(fā)送。如果好幾個節(jié)點同時發(fā)送數(shù)據(jù)，這時候總線上的數(shù)據(jù)將會變成不可用的。這種情況稱為碰撞。 我們知道， CSMA/CD介質(zhì)訪問方式是采用二進(jìn)制指數(shù)退避算法來確定沖突產(chǎn)生以后的等待時 間，第 n次沖突發(fā)生時等待時間可以表示如下 [16]： Min ( [ 0 , 2 1 ] , 102 3 )nT rand?? ? ? 1 n 16?? () ? 為 512位時，對快速以太網(wǎng)來講是 , rand [0, 21n? ]是 0到 21n? 間的一個隨機(jī)整數(shù)。沖突次數(shù)越多， 等待時間可能越長，沖突最多可以 16次，這是由網(wǎng)卡硬件實現(xiàn)的。 這就 會導(dǎo)致后到先服務(wù)的結(jié)果，也會產(chǎn)生所謂的捕獲效應(yīng) (Capture Effect)，這效應(yīng)導(dǎo)致了少數(shù)傳送成功的用戶，可以不斷的使用頻道，傳送失敗的用戶便很難取得頻道，造成帶寬資源分配的不平均。以太網(wǎng)的媒質(zhì)訪問協(xié)議 CSMA/CD以及對碰撞處理的 BEB算法造成了節(jié)點對媒質(zhì)訪問的時間的不確定性，而這種不確定性是實時傳輸需要極力避免的。 通過對以太網(wǎng)傳輸?shù)臏y試結(jié)果可知 [17]，在 20％左右負(fù)荷時，以太網(wǎng)的傳輸延遲增加不多、數(shù)值也不大，可以滿足一般的實時應(yīng) 用環(huán)境，如工業(yè)控制、數(shù)據(jù)采集等，其實時性能甚至比經(jīng)常用于實時應(yīng)用的 (令牌總線局域網(wǎng) )還要好；在 30％左右負(fù)荷時，傳輸延遲有明顯的增大，其數(shù)值對某些強(qiáng)實時應(yīng)用已經(jīng)滿足不了要求；在 50％以上的負(fù)荷時，傳輸延遲大大超出實時應(yīng)用一般的要求范圍，不再具備實時性。 測試時對丟失數(shù)據(jù)包次數(shù)的統(tǒng)計結(jié)果表明，快速以太網(wǎng)在 20%以上負(fù)荷時開始有丟失數(shù)據(jù)包的現(xiàn)象，在 50%以上負(fù)荷丟失情況更加嚴(yán)重。隨著負(fù)荷的增加，快速以太網(wǎng)的可靠性也隨著降低。 為此，一旦有節(jié)點要發(fā)送音頻數(shù)據(jù)就進(jìn)行實時模式與普通模式之間的切換，這 樣在虛擬令牌環(huán)模式和