基于A2DP框架的近距离无线音频通信研究

随着蓝牙技术在电子产品中的日益普及，蓝牙音频设备也层出不穷，其中具有免提功能的蓝牙耳机和蓝牙音频网关的应用是最典型的例子。但免提单元与音频网关进行音频传输建立起来的SCO连接，仅能支持64Kb/s电信级语音质量的音频流，这也就限制了蓝牙音频质量的提高，同时也影响了蓝牙的娱乐消费市场。为了满足人们对高质量音频的需求，进一步扩大蓝牙产品市场，蓝牙特殊兴趣小组SIG组织，在蓝牙  1.1规范的应用框架基础上又单独提出了高级音频分发框架（Advanced Audio Distribution Profile，A2DP）。该框架利用了在L2CAP层建立起来的ACL异步无连接链路来传输高质量的单声道或者立体声音频数据，有效负载的传输速率可以达到300～400Kb/s。
  
  A2DP框架概述
  在娱乐消费市场中，A2DP实例化应用就是用音乐播放器把音频数据通过ACL连接发送到耳机或者音箱上。目前的框架规范中，并不支持同步的一点对多点的广播式音频分发，而对于点对点音频的分发，又存在着两种不同的角色，一个是信源设备（SRC），这种设备作为发起者将数字音频流发送到Piconet网中；另一个是信宿设备，是接收信源发出的音频流的设备。如果蓝牙音乐播放器是信源设备，那么与之交互的蓝牙耳机就是信宿设备，信源和信宿的区别就在于，它是发起者还是接收者。下面对该框架所涉及的具体协议和其依赖框架进行分析。
  
  1 A2DP应用框架
  在典型的蓝牙音频相关框架的整体结构中，A2DP框架所处的位置如图1所示。
  服务发现应用框架（SDAP）所提供的功能，是向其他蓝牙设备提供自身所具备的服务，并且能够使用远程设备所提供的服务和功能。在实际应用中，几乎所有框架都支持服务发现协议（SDP）。蓝牙音频视频遥控应用框架（AVRCP）实现了蓝牙设备之间的遥控功能，例如，音乐播放器的前进、后退、停止、播放等控制信令的传输。免提功能头戴式设备应用框架（HFP/HSP），最主要的应用就是实现了蓝牙耳机的免提功能和某些蓝牙设备的音频网关功能。
  
  高级音频分发框架（A2DP）依赖于通用音频视频分发框架（GAVDP），GAVDP定义了设置音频和视频流传输的步骤，而A2DP则进一步定义了音频流传输的参数和步骤细节。
  
  在实际应用中，逻辑链路控制适配层协议（L2CAP）要求比较高的可靠性，基带的广播数据分组将被禁止使用，因此，L2CAP层并不支持可靠的多点传输信道，这也就是A2DP框架不支持多点广播式音频分发的主要原因之一。而对于面向高层协议的开发和应用者，L2CAP层协议是透明的，因此这里对A2DP轻型框架具体实现的相关描述，也仅限于L2CAP层以上，A2DP相关的协议及框架如AVDTP、GAVDP等协议模块的设计。
  
  
  
  图1 蓝牙音频框架整体结构
  
  图1中的蓝牙主机控制接口HCI层，是协议栈中软硬件的接口。这里所涉及的硬件环境是主机与主机控制器连接模型，HCI层以上的协议（如SDP）在主机上运行，而以下的协议（如传输层的蓝牙基带协议等）由蓝牙主机控制器硬件来完成，这样既保证了底层协议传输的稳定性，又支持了上层应用协议的可扩展性。一旦在市场条件成熟，蓝牙技术的硬件部分就可以被更快的硬件射频技术所取代，高层传输协议经过移植仍然可以沿袭使用，大大缩短蓝牙产品的研发周期。
  
  2 A2DP框架协议栈
  A2DP是音频传输框架，它通过蓝牙传输层和对等设备，把音频数据流从音频信源（SRC）到音频信宿（SNK）进行分发，因此该框架所包含的协议栈也分为两个部分，具体表现如图2所示。
  
  
  
  图2 A2DP框架协议栈
  
  基带协议（Baseband Protocol）、链路管理协议（LMP）、逻辑链路控制和适配协议（L2CAP）及服务发现协议（SDP），在蓝牙核心协议规范中都有定义。而蓝牙音频视频分发传输协议AVDTP则定义了蓝牙设备之间数据流句柄的参数协商、建立和传输过程以及相互交换的信令实体形式，该协议是A2DP框架的基础协议。
  
  轻型A2DP框架协议实现
  这里所提出的A2DP框架协议的实现集中在音频信源端，并未设计信宿端。之所以定义为轻型的，是因为在A2DP规范1.0基础之上，实现了此规范所规定的强制性功能，即在信源端仅仅实现了高级音频分发的基本功能，如立体声音频的传输，只支持低复杂度子带编解码（SBC）标准，而对其他编解码标准并未涉及；在A2DP模块的实现中并未包括任何的编解码能力，这是在用户层上实现的，是上层应用程序在设置阶段，通过配置协商来做相应的编码，解码和音频内容的转换工作；AVDTP模块的功能不包括校验和报告，也不包括媒体多路复用，校验和报告通道的建立。
  
  1 协议模块划分
  A2DP框架协议划分了3个模块：A2DP模块、GAVDP模块和AVDTP模块，另外还包括测试协议栈所需要的Audio应用程序测试模块。对于GAVDP，虽然该功能模块包括音频/视频两种数据流的传输与分发，但是由于这里侧重对音频流进行讨论，所以视频流相关模块（VDP）并未实现。图3是具体实现模块划分图。
  
  
  
  图3 A2DP框架具体模块划分



2 消息传递机制
该轻型框架模块协议层之间的交互是通过消息传递机制来实现的，消息的种类可分为以下4种。
①请求消息REQ
该消息是上层协议向下层协议主动发出的请求。
②确认消息CFM
上层协议发出的每个REQ消息，都会收到下层协议发上来的确认。
③指示消息IND
该消息是下层协议向上层协议主动发起的告知。
④响应消息REP
对于每个下层协议主动发上来的IND消息，上层协议都对此消息进行响应。



图4 协议间的消息传递

协议间的消息传递如图4所示。
采用基于消息传递机制的实现方法的优点如下：
①协议层之间交互通过固定的消息接口，即使上下层协议模块升级，也不会影响本层协议模块的功能，有很好的移植性和可复用性。
②各层协议都是异步通信，可以大大降低拥塞情况的发生。
③协议栈进程可以在上层管理一个消息队列，统一进行消息收发，当消息向下传递过程中遭到拒绝时，可以实现消息的重传功能。
④与每层协议都用一个单独的任务来实现相应功能相比，采用消息机制的方法节省了系统调度时间，更具有实时性，同时避免了死锁的发生。
3 重要数据结构
①消息结构体
消息结构体分为3个域：发送模块Id、接收模块Id、消息枚举类型。具体定义如下：
typedef struct
{
  BT_ModuleId　sender;
  BT_ModuleId　receiver;
  BT_Primitive      primitive;
} BT_Header；
②流端点结构体
流端点SEP存在于应用层中，而应用层又在AVDTP中注册它的SEP，使其他设备可以发现和连接。SEP在3个模块-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；
4 各模块主要功能及消息接口
各模块是通过自己的消息函数来接收不同的枚举消息，并转向各自的消息处理函数，下面具体分析每个模块所实现功能。
①A2DP模块
A2DP模块实现了通过GAVDP管理SEP和SEP能力的功能，并且在SRC和SNK之间为音频流文本设置和配置了流通道。根据A2DP模块的通信流程把它的消息接口分为6种类型：流设置消息，它又可分为对等流端点发现和流配置两个步骤；流通道释放消息；开始/挂起流消息；配置/重新配置消息；发现/得到能力消息；媒体流开始消息。
②GAVDP模块
GAVDP模块从多个使用者角度出发，管理本地流SEP和SEP能力的注册，处理从远程设备发来的发现查询请求和得到能力请求，同时基于用户注册的SEP信息，自动发送响应。
由于GAVDP模块的功能是上层A2DP模块的细化，因此可以将GAVDP的消息接口和A2DP模块的接口类型作一致性设计，两者消息接口类型基本相同。
③AVDTP模块
AVDTP模块负责建立一个到远程蓝牙设备的AVDTP信令通道，并借助于AVDTP协议发送所有的信令命令，同时为媒体流建立传输通道，必要的话为校验和报告也建立通道，另外还支持信令和媒体消息的分段。AVDTP模块数据通信最基本的流程为SEP发现→获取SNK能力→数据流配置→数据流建立→数据流开始→数据流挂起→数据流重新配置→数据流释放。相应的SEP在AVDTP模块中的状态机如图5所示。



图5 SEP在AVDTP模块中的状态机

整个通信过程各个状态之间的跃迁靠下列消息来触发：
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的空闲状态。

测试及结论
该轻型协议栈的实现与测试，可以基于CSR先进的BlueCore4蓝牙芯片来完成。该芯片支持蓝牙2.0+EDR规范，并提供2.1Mb/s的数据传输速率，比标准蓝牙快3倍，可实现更快速的连接，同步支持多个蓝牙链路，以及音频流等更宽带宽的新兴应用。最上层的音频应用程序实现了一个简单的具有处理SBC格式编解码信息的播放器，该应用程序和部分高层协议栈通过交叉编译，下载到硬件平台主机端。而播放器程序是通过调用本协议栈提供的API，进行音频数据流分发。对于音频数据的接收端SNK，采用摩托罗拉HT820立体声耳机进行测试，在长时间播放音频数据的情况下，仍然会存在音频停顿的现象。使用一种截获空中蓝牙信号并进行协议分析的工具Airsniffer，抓取流媒体传输数据包，经分析，音频数据并未丢失，而是流控机制存在问题，需要进一步完善。