摘要：通过对蓝牙高级音频分发框架(A2DP)协议栈进行系统地分析，提出了一种基于消息机制的协议方案，在无A2DP框架的蓝牙1.1协议栈基础上实现了轻型的A2DP应用框架，并且利用嵌入式蓝牙开发平台，实现了基本的点对点蓝牙立体声音频数据的传输。
关键词：蓝牙；高级音频分发框架；消息机制；立体声音频流

引言
近年来，随着蓝牙技术在电子产品中的日益普及，蓝牙音频设备也层出不穷，其中具有免提功能的蓝牙耳机和蓝牙音频网关的应用是最典型的例子。但免提单元与音频网关进行音频传输建立起来的SCO连接，仅能支持64kbps电信级语音质量的音频流，这也就限制了蓝牙音频质量的提高，同时也影响了蓝牙的娱乐消费市场。为了满足人们对高质量音频的需求，进一步扩大蓝牙产品市场，蓝牙特殊兴趣小组SIG组织，在蓝牙1.1规范的应用框架基础上又单独提出了高级音频分发框架(Advanced Audio Distribution Profile, A2DP)。该框架利用了在L2CAP层建立起来的ACL异步无连接链路来传输高质量的单声道或者立体声音频数据，有效负载的传输速率可以达到300kbps~400kbps。
1 A2DP框架概述
在娱乐消费市场中，A2DP实例化应用就是用音乐播放器把音频数据通过ACL连接发送到耳机或者音箱上。目前的框架规范中，并不支持同步的一点对多点的广播式音频分发，而对于点对点音频的分发，又存在着两种不同的角，一个是信源设备(SRC)，这种设备作为发起者将数字音频流发送到Piconet网中；另一个是信宿设备，是接收信源发出的音频流的设备。如果蓝牙音乐播放器是信源设备，那么与之交互的蓝牙耳机就是信宿设备，信源和信宿的区别就在于它是发起者还是接收者。
下面对该框架所涉及的具体协议和其依赖框架进行分析。
1.1 A2DP应用框架
在典型的蓝牙音频相关框架的整体结构中，A2DP框架所处的位置如图1所示：




图1 蓝牙音频框架整体结构
服务发现应用框架(SDAP)所提供的功能是向其他蓝牙设备提供自身所具备的服务，并且能够profile中文
使用远程设备所提供的服务和功能。在实际应用中，几乎所有框架都支持服务发现协议(SDP)。蓝牙音频视频遥控应用框架(AVRCP)实现了蓝牙设备之间的遥控功能，例如音乐播放器的前进，后退，停止，播放等控制信令的传输。免提功能头戴式设备应用框架(HFP/HSP)，最主要的应用就是实现了蓝牙耳机的免提功能和某些蓝牙设备的音频网关功能。
高级音频分发框架(A2DP)依赖于通用音频视频分发框架(GAVDP),GAVDP定义了设置音频和视频流传输的步骤，而A2DP则进一步定义了音频流传输的参数和步骤细节。
在实际应用中，逻辑链路控制适配层协议(L2CAP)要求比较高的可靠性，基带的广播数据分组将被禁止使用，因此，L2CAP层并不支持可靠的多点传输信道，这也就是A2DP框架不支持多点广播式音频分发的主要原因之一。而对于面向高层协议的开发和应用者来说，L2CAP层协议是透明的，因此笔者对A2DP轻型框架具体实现的相关描述，也仅限于L2CAP层以上，与A2DP相关的协议及框架如AVDTP，GAVDP等协议模块的设计。
图中的蓝牙主机控制接口HCI层，是协议栈中软硬件的接口。本文所涉及的硬件环境是主机与主机控制器连接模型，HCI层以上的协议（如SDP）在主机上运行，而以下的协议（如传输层的蓝牙基带协议等）由蓝牙主机控制器硬件来完成，这样既保证了底层协议传输的稳定
性，又支持了上层应用协议的可扩展性。一旦在市场条件成熟，蓝牙技术的硬件部分就可以被更快的硬件射频技术如UWB技术所取代，高层传输协议经过移植仍然可以沿袭使用，大大缩短了蓝牙产品的研发周期。
1.2 A2DP框架协议栈
A2DP是音频传输框架，它通过蓝牙传输层和对等设备，把音频数据流从音频信源(SRC)到音频信宿(SNK)进行分发，因此该框架所包含的协议栈也分为两个部分，具体表现如图2所示：
图2 A2DP框架
基带协议Baseband Protocol,链路管理协议LMP,逻辑链路控制协议L2CAP和服务发现协议SDP，在蓝牙核心协议规范中都有定义。而蓝牙音频视频分发传输协议AVDTP则定义了蓝牙设备之间数据流句柄的参数协商，建立和传输过程以及相互交换的信令实体形式，该协议是A2DP框架的基础协议。
2 轻型A2DP框架协议实现
笔者所提出的A2DP框架协议的实现集中在音频信源端，并未设计信宿端。之所以定义为轻型的，是因为在A2DP规范1.0基础之上，实现了此规范所规定的强制性功能，即在信源端仅仅实现了高级音频分发的基本功能，如立体声音频的传输，只支持低复杂度子带编解码(SBC)
标准,而对其他编解码标准并未涉及；在A2DP模块的实现中并未包括任何的编解码能力，这是在用户层上实现的，是上层应用程序在设置阶段，通过配置协商来做相应的编码，解码和音频内容的转换工作；AVDTP模块的功能不包括校验和报告，也不包括媒体多路复用，校验和报告通道的建立。
2.1 协议模块划分
A2DP框架协议划分了三个模块：A2DP模块,GAVDP模块,AVDTP模块，另外还包括测试协议栈所需要的Audio应用程序测试模块。对于GAVDP，虽然该功能模块包括音频/视频两种数据流的传输与分发，但是由于笔者侧重对音频流的讨论，所以视频流相关模块(VDP)并未实现。图3是具体实现模块划分图：
图3 具体模块划分
2.2 消息传递机制
该轻型框架模块协议层之间的交互是通过消息传递机制来实现的。消息的种类可分为四种：（1）请求消息REQ，该消息是上层协议向下层协议主动发出的请求；（2）确认消息CFM，上层协议发出的每个REQ消息，都会收到下层协议发上来的确认；（3）指示消息IND,该消息是下层协议向上层协议主动发起的告知；（4）响应消息REP,对于每个下层协议
主动发上来的IND消息，上层协议都对此消息进行响应。如图4所示：

图4 协议间消息传递

采用基于消息传递机制的实现方法优点在于：
1）协议层之间交互通过固定的消息接口，即使上下层协议模块升级，也不会影响本层协议模块的功能，有很好的移植性和可复用性；
2）各层协议都是异步通信，可以大大降低拥塞情况的发生；
3）协议栈进程可以在上层管理一个消息队列，统一进行消息收发，当消息向下传递过程中遭到拒绝时，可以实现消息的重传功能。
4）与每层协议都用一个单独的任务来实现相应功能相比，采用消息机制的方法节省了系统调度时间，更具有实时性，同时避免了死锁的发生。
2.3 重要数据结构
2.3.1消息结构体
消息结构体分为三个域：发送模块Id、接收模块Id、消息枚举类型，具体定义如下：
typedef struct
{
BT_ModuleId sender;
BT_ModuleId receiver;
BT_Primitive primitive;
} BT_Header
2.3.2流端点结构体
流端点SEP存在于应用层中，而应用层又在AVDTP中注册它的SEP，使其他设备可以发现和连接。SEP在三个模块A2DP, GAVDP, AVDTP中有着不同的结构体类型，以适应本层协议的特殊作用，以A2DP模块为例，其SEP结构体具体定义如下：
typedef struct
{
GAVDP_Handle streamHandle;
BT_U8 *codecInfoElement;
BT_U8 lengthInfoElements;
AVDT_MediaCodecType codecType;
ChannelConfig configuration;
AVDT_ResponseCode pendingRspCode;
BT_TimerId resendTimerId;
} StreamEndPoint
2.4 各模块主要功能及消息接口
各模块是通过自己的HandleMsg()函数来接收不同的枚举消息，并转向各自的消息处理函数的，下面具体分析每个模块所实现功能。
2.4.1 A2DP模块
该模块实现了通过GAVDP管理SEP和SEP能力的功能，并且在SRC和SNK之间为音频流文本设置和配置了流通道。根据A2DP模块的通信流程把它的消息接口分为以下六种类型：（1）流设置消息，它又可分为对等流端点发现和流配置两个步骤；（2）流通道释放消息；（3）开始/挂起流消息；（4）配置/重新配置消息；（5）发现/得到能力消息；（6）媒体流开始消息。
2.4.2 GAVDP模块
该模块从多个使用者角度出发，管理本地流SEP和SEP能力的注册，处理从远程设备发来的发现查询请求和得到能力请求，同时基于用户注册的SEP信息，自动发送响应。
由于该模块的功能是上层A2DP模块的细化，因此在设计中把它的消息接口和A2DP模块的接口类型做了一致性设计，两者消息接口类型基本相同。
2.4.3 AVDTP模块
该模块负责建立一个到远程蓝牙设备的AVDTP信令通道，并借助于AVDTP协议发送所有的信令命令，同时为媒体流建立传输通道，必要的话为校验和报告也建立通道。另外还支持信令和媒体消息的分段。
该模块数据通信最基本的流程为：SEP发现 获取SNK能力 数据流配置 数据流建立 数据流开始 数据流挂起 数据流重新配置 数据流释放。
相应的SEP在AVDTP模块中的状态机如图5所示：
图5 SEP状态机
整个通信过程各个状态之间的跃迁靠下列消息来触发：
A: AVDT_SET_CONFIGURATION_REQ
B: AVDT_OPEN_REQ
C: AVDT_START_REQ
D: AVDT_SUSPEND_REQ
E: AVDT_CLOSE_REQ
F: AVDT_ABORT_REQ
G: AVDT_RECONFIGURE_REQ
H: AVDT_MEDIA_REQ
在空闲状态下，发送A消息之前，空闲状态下要发出一系列动作，包括连接请求，发现请求，获取SNK能力请求等。从空闲态到配置态的跃迁过程，本协议栈统称为流设置过程。
在打开状态下发送C消息之后，就进入了流控状态，此时通过H消息就可以发送从SRC到SNK的媒体流数据包。
在通信过程中的任何状态下，都可以通过发送F消息，进入中止态，进而回到没有连接任何远程SEP的空闲状态。
3 硬件平台及测试
该轻型协议栈的实现与测试，是基于CSR先进的BlueCore4蓝牙芯片来完成的。该芯片支持蓝牙2.0+EDR规范，并提供2.1Mbps的数据传输速率，比标准蓝牙倍，可以实现更快速
的连接，同步支持多个蓝牙链路，以及音频流等更宽带宽的新兴应用。最上层的音频应用程序实现了一个简单的具有处理SBC格式编解码信息的播放器，该应用程序和部分高层协议栈通过交叉编译，下载到硬件平台主机端。而播放器程序是通过调用本协议栈提供的API，进行音频数据流分发。
对于音频数据的接收端SNK，我们采用摩托罗拉HT820立体声耳机进行测试，在长时间播放音频数据的情况下，仍然会存在音频停顿的现象。使用一种截获空中蓝牙信号并进行协议分析的工具Airsniffer，抓取流媒体传输数据包，经分析，音频数据并未丢失，而是流控机制存在问题，需要进一步完善。
4 结束语
笔者在蓝牙1.1协议规范的核心协议和应用框架的基础上，设计并实现了轻型A2DP框架，提出了一种基于消息传递机制的协议方案，并通过实际测试，已完成高级音频传输的基本功能。但是该协议仍然有很多不完善的地方，如通信状态反复切换的系统稳定性，消息重传机制，安全控制等方面都需要进一步改进。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。