BAP:基本音频配置(The Basic Audio Profile )。这一层主要定义了音频的控制规范,我们来看看它的协议框架图:
BAP的六种角色(role):
Unicast Server:单播服务端
Unicast Client :单播客户端
Broadcast Source :广播源端
Broadcast Sink :广播接收端
Broadcast Assistant:广播助手
Scan Delegator:扫描代理
我们主要介绍前面四种角色,首先BAP定义了单播和广播角色模式。
单播角色( Unicast role):蓝牙需要建立连接,对连接数量,芯片平台也有限制。这个就是基于连接的模式,包含服务端( Server )和客户端( Client ),支持音频数据的双向传输。
广播角色( Broadcast role ):蓝牙不用建立连接,一个作为是广播源端,可以有不限数量的接收端。这个模式是单向传输的,即音频数据流只能从源端(Source)传到接收端(Sink) 。
BAP角色之间的关系:
Unicast Server和Unicast Client 连接的关系图:
这里可以看到Unicast Server端包含了ASCS和PACS服务
ASCS:Audio Stream Control Service 音频流控制服务
PACS: Published Audio Capabilities Service 发布的音频能力服务
Unicast Client通过获取Unicast Server端的PACS服务,可以知道Unicast Server端的音频能力,比如支持的音频编解码,采样率,声道数等。
Unicast Client通过获取Unicast Server端的ASCS服务,来控制Unicast Server端音频流的配置,使能以及反馈音频状态等等。
Unicast Client和Unicast Server端是可以通过建立蓝牙连接通信,从而建立起音频播放流程。那么Broadcast Source和Broadcast Sink 端又是如何实现呢?我们来看看关系图:
这里可以看出, Broadcast Source端的数据往Broadcast Sink 端流,是单向的。大致流程是这样的:
Broadcast Source端发起扩展广播,创建同步广播(广播包含PACS 服务定义的音频能力等特性),建立ISO数据流通道,开始往ISO通道启动音频发送。
Broadcast Sink端扫描广播,同步同步广播的数据,获取Source端的音频能力,建立ISO数据流通道,接收ISO通道的音频数据。
这章节主要是对le audio的bap协议中的角色做了简单的介绍,让大家对bap有个基本的认识。在后面的章节中,会在nrf5340平台用具体的实例来做分析。