DIY的乐趣：打造你自己的WiFi“云”播放器，提供软硬件设计方案

1.项目背景

随着互联网的发展，网络应用已经渗透到人们生活的各个方面。人们正在通过各种设备享受着网络带来的便利。"云"平台，"云计算"等技术的应用，使得我们可以通过更简单的设备享受到更加丰富多彩的网络服务。我们的Cloud Player正式基于"云"服务这样的概念，实现一个Server和Client结构的音乐播放器。播放器本身不存储音乐文件，用户可以通过从服务器下载播放列表来获得所需类型的音乐，然后通过无线的方式播放服务器端的音乐文件。

2.项目方案

2.1硬件设计方案

2.1.1主要硬件模块

MCU: PIC32 (80 MHz 32位MIPS处理器)

WiFi模块

液晶屏

音频放大

扬声器

键盘/按键

2.1.2硬件设计框图

2.2软件设计方案

2.2.1关于WiFi无线通信

软件按照部署划分可以分为PC上的服务程序和Cerebot 32MX4上的Cloud Player程序，按照功能模块细分这两部分涉及到的主要有PC端：Qt/gtk界面设计、linux网络编程、linux WiFi通讯驱动、数据库操作、文件传输以及PC端对外提供服务的原语的设计；CloudPlayer 端：WiFi模块的驱动、网络协议栈的移植、音频解码、液晶屏驱动、按键驱动以及获取服务原语的设计。

系统网络结构示意图如下所示：

PIC开发板（客户端）WiFi通信

WiFi通信作为基本的网络功能，是云播放器多媒体文件传输实现的基础。在实现上主要有4个层次：

射频收发

调制解调层

介质访问层/MAC

协议栈控制层

其中射频收发、MAC层和调制解调将在开发商的WiFi模块产品中完成，通信程

序开发的重点集中在协议层和应用的实现。通过硬件模块的SPI接口控制，WiFi设备将完成设备初始化、信息查询、设备探测和连接建立等过程；通信过程则需要进行数据的收发和通信状态管理。其中数据收发将采用查询式发送和中断式接收的方法；通信状态管理则需要管理连接断开、数据校验纠错等过程。WiFi通信基本软件流程如图所示：

在WiFi通信的软件系统中，驱动程序是基础也是重点，这一部分将详细参照模块生产厂商的相关资料进行开发。

图、WiFi协议栈基本层次结构

PC（服务器端）WiFi通信

服务器端将使用带WiFi的笔记本进行开发。PC端开发将建立在Linux操作系统之上，利用Linux网络API对WiFi模块数据收发、连接管理等进行控制。同时，服务器需要建立多进程/线程的C/S结构服务程序，以满足多用户WiFi接入的需要求。

2.2.2服务模型

系统服务模型的基本单位包括服务器端（PC）、客户端（PIC32开发板）以及wifi通信媒介。通信媒介既可由基站（Base Station，BS）、访问点（Access Point，AP）进行协调，也可采用自由直连（ad hoc）方式。

云播放系统中，客户播放器（PIC32开发板）的主要数据，包括用户信息，收藏列表，播放、搜索和其他操作记录以及用于播放的音频文件，都放置在云端存储中。客户端启动时，首先搜索范围内可用wifi网络，选择合适的AP完成网络加入（必要时提供密钥）。通过wifi网络建立与云端服务器的连接，完成身份验证，继而进行收藏列表下载、选择曲目播放和音乐搜索等功能。

云播放系统服务模型中，需要综合考虑客户端与wifi网络AP、客户端与云端服务器的交互。典型的需求约束包括如下所述：

客户端通过扫描识别可用wifi网络。在预知各网络状态的情况下，自动进行连接。或由用户自主选择加入的网络，必要时需提供网络密钥。

首次联机时，服务器将客户端固化的唯一序列号进行注册，在云端存储上分配用户信息、初始收藏列表及操作列表等相应的空间。

非首次联机时，服务器端根据客户端发送的序列号进行用户收藏列表的推送。

用户选择收藏列表中确定位置曲目开始播放，由服务器端将曲目信息（名称、艺术家、时长、音质、同步歌词等）和音频流通过wifi网络传输至客户端。客户端只进行当前播放范围数据的缓存，并实时解码播放音频流。

收藏列表管理，包括相应曲目的添加、修改和删除操作。客户端操作与服务器端存储进行同步更新。

服务器端提供音乐搜索功能，客户可根据搜索结果完成新曲目的添加。

服务器端维护连接状态管理。通过周期性查询客户端响应获取当前连接状态，客户端失去连接时，关闭相关的数据传输流和内存中分配空间。

预期可选的高级服务如下所述：

QoS。客户端音频流媒体的良好播放体验需QoS（Quality of Service，服务质量）的支持，提供实时低延迟、低丢包率抖动的音频传输。可采取的措施包括引入资源预留协议（RSVP）、采用动态组播等方式，wifi协议本身也