基于Wi-Fi Direct的音频传输系统（APP前端+Java服务端）

资源下载地址：https://download.csdn.net/download/sheziqiong/85996746
资源下载地址：https://download.csdn.net/download/sheziqiong/85996746

摘要

我们实现了一个软件系统：它可以通过Wi-Fi Direct建立一个网络，自主发现网络中的某一设备并向该设备发送音频信号。该设备收到音频信号后，如果有多个来源，将对这些音频信号混频。最终这个设备讲接收的音频信号播放。

目录
摘要 1
一、 Wi-Fi Direct技术 1
二、 服务发现协议、心跳协议和音频控制协议 1
三、 RTP协议和RTCP协议 3

1. RTP概览 3
2. RTP的封装格式 3
3. RTCP的封装结构 4
4. RTP的会话过程 5
5. 音频数据的处理 5
6. 安卓端 7
7. PC端 8

2.服务发现协议、心跳协议和音频控制协议

在该部分，我们称音频信号的发送者为Client端，音频信号的接受者为Server端。

在我们设想的情景中，Server端可能是网络中的任意一台设备，因此Server端的地址是不确定的。如果让用户自行寻找Server端的地址，这显然是一件不合理的事情，因此我们需要设计一个服务发现协议，让Client端可以自动的发现网络中的Server端。同时，为了确保通信的正确进行，我们需要Server端和Client端每隔一段时间都去确认双方是否都还在当前网路中。为此我们设计了心跳协议。

为了方便Server端接收并播放音频流，Client端在开始发送音频前和停止发送音频后，都应该向Server端告知自身当前的播放状态。因此我们设计了音频控制协议。

服务发现协议和心跳协议如图1所示。其过程大致如下：

1. Client端：向网络广播消息“client”，表示有新的Client加入网络中。

2. Server端：在接受到广播消息后，向广播源（即对应的Client）发送消息“server”，表明自己的身份。

心跳协议由Client端定时执行。其过程大致如下：

1. Client端：向Server发送心跳消息“server?”并等待回复。如果不能在较短时间内接收到Server的回复，则认为该Server已经离开网络。

2. Server端：接收到Client的心跳消息后回复消息“serverYes”。如果在规定时间内没有接收到Client的心跳消息，则认为该Client已经离开网络。

图1：服务发现协议和心跳协议

音频控制协议如图2所示。音频控制协议包含两种子协议：请求播放和请求暂停。其过程大致如下：

请求播放：

• Client端：向Server发送消息“play”。

• Server端：接收到消息后，准备好接收音频流，并向Client发送消息“playOk”。

• Client端：接收到消息后，通过RTP协议向Server发送音频信号。