資源下載地址：https://download.csdn.net/download/sheziqiong/85996746
資源下載地址：https://download.csdn.net/download/sheziqiong/85996746

摘要

我們實現(xiàn)了一個軟件系統(tǒng)：它可以通過Wi-Fi Direct建立一個網(wǎng)絡(luò)，自主發(fā)現(xiàn)網(wǎng)絡(luò)中的某一設(shè)備并向該設(shè)備發(fā)送音頻信號。該設(shè)備收到音頻信號后，如果有多個來源，將對這些音頻信號混頻。最終這個設(shè)備講接收的音頻信號播放。

目錄
摘要 1
一、 Wi-Fi Direct技術(shù) 1
二、 服務(wù)發(fā)現(xiàn)協(xié)議、心跳協(xié)議和音頻控制協(xié)議 1
三、 RTP協(xié)議和RTCP協(xié)議 3

RTP概覽 3

RTP的封裝格式 3

RTCP的封裝結(jié)構(gòu) 4

RTP的會話過程 5

音頻數(shù)據(jù)的處理 5

安卓端 7

PC端 8

2.服務(wù)發(fā)現(xiàn)協(xié)議、心跳協(xié)議和音頻控制協(xié)議

在該部分，我們稱音頻信號的發(fā)送者為Client端，音頻信號的接受者為Server端。

在我們設(shè)想的情景中，Server端可能是網(wǎng)絡(luò)中的任意一臺設(shè)備，因此Server端的地址是不確定的。如果讓用戶自行尋找Server端的地址，這顯然是一件不合理的事情，因此我們需要設(shè)計一個服務(wù)發(fā)現(xiàn)協(xié)議，讓Client端可以自動的發(fā)現(xiàn)網(wǎng)絡(luò)中的Server端。同時，為了確保通信的正確進行，我們需要Server端和Client端每隔一段時間都去確認雙方是否都還在當前網(wǎng)路中。為此我們設(shè)計了心跳協(xié)議。

為了方便Server端接收并播放音頻流，Client端在開始發(fā)送音頻前和停止發(fā)送音頻后，都應(yīng)該向Server端告知自身當前的播放狀態(tài)。因此我們設(shè)計了音頻控制協(xié)議。

服務(wù)發(fā)現(xiàn)協(xié)議和心跳協(xié)議如圖1所示。其過程大致如下：

Client端：向網(wǎng)絡(luò)廣播消息“client”，表示有新的Client加入網(wǎng)絡(luò)中。

Server端：在接受到廣播消息后，向廣播源（即對應(yīng)的Client）發(fā)送消息“server”，表明自己的身份。

心跳協(xié)議由Client端定時執(zhí)行。其過程大致如下：

Client端：向Server發(fā)送心跳消息“server?”并等待回復(fù)。如果不能在較短時間內(nèi)接收到Server的回復(fù)，則認為該Server已經(jīng)離開網(wǎng)絡(luò)。

Server端：接收到Client的心跳消息后回復(fù)消息“serverYes”。如果在規(guī)定時間內(nèi)沒有接收到Client的心跳消息，則認為該Client已經(jīng)離開網(wǎng)絡(luò)。

圖1：服務(wù)發(fā)現(xiàn)協(xié)議和心跳協(xié)議

音頻控制協(xié)議如圖2所示。音頻控制協(xié)議包含兩種子協(xié)議：請求播放和請求暫停。其過程大致如下：

請求播放：

• Client端：向Server發(fā)送消息“play”。

• Server端：接收到消息后，準備好接收音頻流，并向Client發(fā)送消息“playOk”。

• Client端：接收到消息后，通過RTP協(xié)議向Server發(fā)送音頻信號。

請求暫停：

• Client端：向Server發(fā)送消息“stop”并停止發(fā)送音頻信號。

圖2：音頻控制協(xié)議

3.RTP協(xié)議和RTCP協(xié)議

3.1 RTP概覽

我們項目中對音頻信號的傳輸是通過RTP實現(xiàn)的。RTP協(xié)議詳細說明了在互聯(lián)網(wǎng)上傳輸音頻和視頻的標準數(shù)據(jù)包格式，常用于流媒體系統(tǒng)中，是一個多播協(xié)議但也可以用于單播應(yīng)用中，非常符合我們項目的需求。

RTP協(xié)議是一種基于UDP的無連接的傳輸協(xié)議，和RTCP控制協(xié)議一起使用。RTP協(xié)議為Internet上端到端的實時傳輸提供時間信息和流同步，但它并不保證服務(wù)質(zhì)量。服務(wù)質(zhì)量控制功能由RTCP協(xié)議來提供。

圖3展示了一個典型流媒體應(yīng)用的體系結(jié)構(gòu)。RTP協(xié)議被劃分在傳輸層，建立在UDP上。因此，同UDP協(xié)議一樣，為了實現(xiàn)實時傳輸功能，RTP也有固定的封裝形式，接下來將具體介紹RTP數(shù)據(jù)包的封裝結(jié)構(gòu)。

圖3：典型流媒體應(yīng)用的體系結(jié)構(gòu)

3.2 RTP的封裝格式

圖4展示了RTP報文的頭部格式。其各部分含義如下：

• 版本號（V）：2比特，用來標志使用的RTP版本。
• 填充位（P）：1比特，如果該位置位，則該RTP包的尾部就包含附加的填充字節(jié)。
• 擴展位（X）：1比特，如果該位置位的話，RTP固定頭部后面就跟有一個擴展頭部。
• CSRC計數(shù)器（CC）：4比特，含有固定頭部后面跟著的CSRC的數(shù)目。
• 標記位（M）：1比特,該位的解釋由配置文檔（Profile）來承擔(dān).
• 載荷類型（PT）：7比特，標識了RTP載荷的類型。
• 序列號（SN）：16比特，發(fā)送方在每發(fā)送完一個RTP包后就將該域的值增加1，接收方可以由該域檢測包的丟失及恢復(fù)包序列。序列號的初始值是隨機的。
• 時間戳（timestamp）：32比特，記錄了該包中數(shù)據(jù)的第一個字節(jié)的采樣時刻。在一次會話開始時，時間戳初始化成一個初始值。即使在沒有信號發(fā)送時，時間戳的數(shù)值也要隨時間而不斷地增加。時間戳是去除抖動和實現(xiàn)同步不可缺少的。
• 同步源標識符（SSRC）：32比特，同步源就是指RTP包流的來源。在同一個RTP會話中不能有兩個相同的SSRC值。該標識符是隨機選取的，用于唯一標識RTP會話中的參與者。
• 貢獻源列表（CSRC List）：0～15項，每項32比特，用來標志對一個RTP混合器產(chǎn)生的新包有貢獻的所有RTP包的源。由混合器將這些有貢獻的SSRC標識符插入表中。SSRC標識符都被列出來，以便接收端能正確指出交談雙方的身份。（混合器用于需要將多個源的音頻包進行合并以及接收者能接收的音頻編碼格式不一致的情況中）

圖4：RTP報文的頭部格式

3.3 RTCP的封裝結(jié)構(gòu)

RTCP也是基于UDP進行傳送的，封裝的主要是一些控制信息，用于檢測與反饋服務(wù)質(zhì)量、同步媒體、標識多播組中的成員等等。在RTP會話期間，各參與者周期性地傳送RTCP包。RTCP包中含有已發(fā)送的數(shù)據(jù)包的數(shù)量、丟失的數(shù)據(jù)包的數(shù)量等統(tǒng)計資料，各參與者可以利用這些信息動態(tài)地改變傳輸速率。RTP和RTCP配合使用，它們能以有效的反饋和最小的開銷使傳輸效率最佳化，因而特別適合傳送網(wǎng)上的實時數(shù)據(jù)。

由于RTCP僅包含一些控制信息，因此分組長度很短，可以將很多RTCP分組封裝在一個UDP包中。RTCP有如下五種分組類型：

類型縮寫表示用途

200	SR(Sender Report)	發(fā)送端報告
201	RR(Receiver Report)	接收端報告
202	SDES(Source Description Items)	源點描述
203	BYE	結(jié)束傳輸
204	APP	特定應(yīng)用

上述五種封裝類型的內(nèi)部結(jié)構(gòu)基本相同，下面以SR為例進行介紹：

發(fā)送端報告分組SR用于使發(fā)送端以多播的方式向所有接收端報告發(fā)送情況，主要內(nèi)容包括：相應(yīng)RTP流的SSRC值、RTP流中最新產(chǎn)生的RTP分組的時間戳、RTP流包含的分組數(shù)、RTP流包含的字節(jié)數(shù)等。圖5展示了RTCP SR頭的結(jié)構(gòu)，其中各部分的含義如下：

• 版本（V）：同RTP包頭域。
• 填充（P）：同RTP包頭域。
• 接收報告計數(shù)器（RC）：5比特，該SR包中的接收報告塊的數(shù)目，可以為零。
• 包類型（PT）：8比特，對應(yīng)上表的五種分組類型。
• 長度域（Length）：16比特，其中存放的是該SR包以32比特為單位的總長度減一。
• 同步源（SSRC）：SR包發(fā)送者的同步源標識符。與對應(yīng)RTP包中的SSRC一樣。
• NTP Timestamp（Network time protocol）SR包發(fā)送時的絕對時間值。NTP的作用是同步不同的RTP媒體流。
• RTP Timestamp：與NTP時間戳對應(yīng)，與RTP數(shù)據(jù)包中的RTP時間戳具有相同的單位和隨機初始值。
• Sender’s packet count：從開始發(fā)送包到產(chǎn)生這個SR包這段時間里，發(fā)送者發(fā)送的RTP數(shù)據(jù)包的總數(shù). SSRC改變時，這個域清零。
• Sender’s octet count：從開始發(fā)送包到產(chǎn)生這個SR包這段時間里，發(fā)送者發(fā)送的凈荷數(shù)據(jù)的總字節(jié)數(shù)（不包括頭部和填充）。發(fā)送者改變其SSRC時，這個域要清零。
• 同步源n的SSRC標識符：該報告塊中包含的是從該源接收到的包的統(tǒng)計信息。
• 丟失率（Fraction Lost）：表明從上一個SR或RR包發(fā)出以來從同步源n(SSRC_n)來的RTP數(shù)據(jù)包的丟失率。
• 累計的包丟失數(shù)目：從開始接收到SSRC_n的包到發(fā)送SR,從SSRC_n傳過來的RTP數(shù)據(jù)包的丟失總數(shù)。
• 收到的擴展最大序列號：從SSRC_n收到的RTP數(shù)據(jù)包中最大的序列號，
• 接收抖動（Interarrival jitter）：RTP數(shù)據(jù)包接受時間的統(tǒng)計方差估計
• 上次SR時間戳（Last SR,LSR）：取最近從SSRC_n收到的SR包中的NTP時間戳的中間32比特。如果目前還沒收到SR包，則該域清零。
• 上次SR以來的延時（Delay since last SR,DLSR）：上次從SSRC_n收到SR包到發(fā)送本報告的延時。

圖5：RTCP SR頭的結(jié)構(gòu)

4.4 RTP的會話過程

當應(yīng)用程序建立一個RTP會話時，需要首先確定一對目的傳輸?shù)刂?#xff0c;包含一個網(wǎng)絡(luò)IP地址以及一對端口號。這對端口號一個用于RTP包，一個用于RTCP包，其中RTP數(shù)據(jù)發(fā)向偶數(shù)的UDP端口，RTCP包發(fā)向相鄰的奇數(shù)UDP端口，這樣就構(gòu)成了一個UDP端口對。圖6展示了RTP包發(fā)送的過程。接收過程與此相反。

圖6：RTP包的發(fā)送流程

4.5 音頻數(shù)據(jù)的處理

處理數(shù)據(jù)前，我們會把音頻數(shù)據(jù)解碼為PCM格式。發(fā)送端讀取音頻文件獲取音頻輸入流，將音頻流切割為指定的塊大小，然后通過RTP發(fā)送。接收端收到字節(jié)流后對其進行處理，通過已打開的相應(yīng)格式的源數(shù)據(jù)行將處理過的字節(jié)流寫入數(shù)據(jù)行中，通過混頻器傳遞到輸出端口。圖7展示了這個過程。

圖7：音頻數(shù)據(jù)的傳輸過程

對于每個發(fā)送者，動態(tài)添加新的與之對應(yīng)的接收buffer和混合buffer，所有buffer大小一定。每次接收到數(shù)據(jù)時將數(shù)據(jù)存入到該數(shù)據(jù)發(fā)送者對應(yīng)的接收buffer中（I），當接收buffer滿，數(shù)據(jù)轉(zhuǎn)移到混合buffer中。如果混合buffer為空，直接轉(zhuǎn)移（II），若混合buffer滿，考慮到兩個及以上個發(fā)送者時，進一步檢測是否所有的buffer均滿（III）。若所有的混合buffer均滿，將當前所有發(fā)送者的混合buffer進行混音，發(fā)送到輸出端口進行播放，并清空當前所有發(fā)送者的混合buffer（IV）；若有混合buffer未滿，則丟棄當前接收者混合buffer中的數(shù)據(jù)，直接將接收buffer數(shù)據(jù)轉(zhuǎn)移（V）。圖8和圖9分別展示了單發(fā)送端和多發(fā)送端的這一處理過程。

同時，在每一輪接收數(shù)據(jù)過程中，檢測每一個發(fā)送者多少輪沒發(fā)送過數(shù)據(jù)。若一定輪次里均沒有發(fā)送過數(shù)據(jù)，則動態(tài)刪除該發(fā)送者的接收和混合buffer。

圖8：單發(fā)送端處理過程

圖8：多發(fā)送端處理過程

我們采用的是帶符號位的PCM編碼方式，每一字節(jié)數(shù)據(jù)在-128~127之間。混音時，取兩個數(shù)據(jù)包的每一字節(jié)，進行以下運算。這樣兩個聲音就可以混合起來。

技術(shù)細節(jié)

在我們的實現(xiàn)中，心跳協(xié)議的重復(fù)時間間隔為30秒，Client端等待時間為1秒。考慮到網(wǎng)絡(luò)傳輸?shù)难訒r，Server端等待時間為30.5秒。

為了實現(xiàn)RTP包的封裝，我們使用jlibrtp庫。圖9展示了jlibrtp庫的使用過程：

• 首先，調(diào)用jlibrtp庫的實時傳輸會話類RTPSession建立收發(fā)端的會話。該類可以創(chuàng)建一個RTP會話，并設(shè)置傳輸?shù)腞TP端口和RTCP端口，以及與RTP包的相關(guān)的時間戳數(shù)據(jù)等。
• 然后，通過RTPSessionRegister方法用于添加RTP會話的參與者，同時開啟接收包的AppCallerThread線程類。線程類的run方法在接受到RTP數(shù)據(jù)包時，會去掉RTP包頭，獲取傳輸數(shù)據(jù)內(nèi)容，并調(diào)用回調(diào)函數(shù)receiveData。在該函數(shù)中，我們將RTP負載存入buffer，然后進行音頻數(shù)據(jù)處理和混頻。

圖9：jlibrtp庫的使用過程

在實現(xiàn)音頻數(shù)據(jù)處理和混頻過程中，我們選擇每個數(shù)據(jù)塊的大小為1024字節(jié)，buffer的大小為30個數(shù)據(jù)塊。發(fā)送者30輪未發(fā)送數(shù)據(jù)后將會被刪除。

buffer的大小會影響丟包率。如果buffer過小，會導(dǎo)致丟包率升高。buffer過大，則會浪費大量的內(nèi)存空間。

實現(xiàn)內(nèi)容

1.安卓端

安卓端 Server 和 Client 由同一軟件完成，如圖10所示。在初始界面運行服務(wù)發(fā)現(xiàn)協(xié)議，由一臺終端發(fā)起連接 (Create New Network) 與其它終端互聯(lián) (Search)。在網(wǎng)絡(luò)中終端互相成功發(fā)現(xiàn)后，每個終端可以通過按鈕切換在音頻傳輸中擔(dān)任的角色 (Server/Client)。通常每一組網(wǎng)絡(luò)中有且僅有一個終端為音頻 Server，用來接收網(wǎng)絡(luò)中 Client 的音頻數(shù)據(jù)并混音播放。

圖10：安卓終端界面

2.PC端

圖11：PC終端界面

PC端在進入軟件開始便選擇自身音頻傳輸中的身份 (Server/Client)。Server 端可以直接啟動并持續(xù)監(jiān)聽網(wǎng)絡(luò)中是否有 Client 傳送數(shù)據(jù)。Client 端則需要搜索網(wǎng)絡(luò)中存在的 Server，主動與其連接并選擇音頻文件進行發(fā)送。

資源下載地址：https://download.csdn.net/download/sheziqiong/85996746
資源下載地址：https://download.csdn.net/download/sheziqiong/85996746

總結(jié)

以上是生活随笔為你收集整理的基于Wi-Fi Direct的音频传输系统（APP前端+Java服务端）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。