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协议本身也对QoS提供了一定的原声支持。

负载均衡。对于范围规模较大情况下的云播放系统，采用分布式的CDN（Content Delivery Network，内容分发网络）是减小服务器压力、提高客户端下载速度的有效手段。此时通过DNS技术，将客户请求连接到最近的缓存服务器得到满足，动态的调节网络负载均衡，达到最快的响应和传输速度。

可适应性编码。采用具有可适应性编码的前提是可进行服务器端与客户端实时传输速率的测量。当出现网络拥塞或带宽限制时，将流媒体编码率适当降低。反之，当网络带宽足量或剩余时，调整音频流至高码率，提供更高品质的音乐体验。

根据上述服务模型的分析，确定了已下的通信原语：

名称	起始方	说明
WIFI_scan	客户端	客户端扫描附近范围的可用wifi网络
WIFI_netInfo	Wifi AP	Wifi网络AP返回网络信息，SSID、信道频率等
WIFI_connect	客户端	客户端连接到一确定的wifi网络，需提供SSID，密钥可选。预期应答为WIFI_ack
WIFI_close	客户端	离开已加入的wifi网络，关闭所有连接。预期应答为WIFI_ack
WIFI_ack	Wifi AP	响应客户端请求的应答
Cloud_1stAdd	客户端	首次联机时，客户端通过序列号完成注册
Cloud_requestList	客户端	客户端向服务器端请求收藏列表。预期应答为Cloud_list
Cloud_list	服务器端	服务器传输的收藏列表
Cloud_play	客户端	客户端选择曲目或列表位置请求音频播放
Cloud_pause	客户端	暂停音频播放
Cloud_addMusic	客户端	向列表中添加新曲目
Cloud_delMusic	客户端	删除列表中特定曲目
Cloud_search	客户端	客户端提交搜索关键字，进行音乐查询。预期结果Cloud_searchRes
Cloud_searchRes	服务器端	搜索动作返回的结果集
Cloud_state	服务器端	对客户端连接状态的查询
Cloud_ack	客户/服务器端	积极的响应应答，表示动作得以执行

典型的系统服务交互过程如下所示：

客户端           AP                服务器端

WIFI_scan

                WIFI_netInfo

WIFI_connect

               WIFI_ack

Cloud_1stAdd

                                   Cloud_ack

Cloud_requestList

                                   Cloud_requestList

Cloud_play

Cloud_pause

Cloud_addMusic                       

                                  Cloud_ack

vCloud_delMusic                         Cloud_ack

Cloud_search                        Cloud_searchRes

                                   Cloud_state

Cloud_ack

2.2.3音频解码

首先调研一下PIC提供的audio library，看能否满足项目的需要。

2.2.4音频播放

音频播放采用PmodAMP1——扬声器/耳机放大器，调用PIC的audio libray对接受到的音频文件进行解码，然后经PWM DAC输出到PmodAMP1。

2.2.5液晶屏显示

液晶屏采用PmodCLS——字符LCD串行接口，通过SPI控制。

2.2.6按键驱动

拟定采用矩阵式按键，采用软件消抖，接受用户输入。