声明: 内容来自：www.bluetooth.com, 加个人理解，仅用于学习交流，如果您发现不对的地方，请不吝赐教。

接收广播音频流

广播拓扑

BMS是广播，不会与BMR建立连接，那BMR有要怎样才能听到BMS的广播音频流呢？
Bluetooth SIG的SPEC提供了多种查找广播的方法。
最简单的情况是，一副耳机自行扫描以查找并选择广播音频流，如下图
在这里插入图片描述

耳机直接同步

也有可能是手机就是BMR，手机通过有线耳机出声，当然手机本地speaker出声也可以，如下图
在这里插入图片描述

使用手机作为BMR

下面应该是最常见的用例：手机、手表或遥控器等设备充当广播助手，扫描并显示所选的广播音频流，然后使用 PAST（周期性广播同步传输功能）帮助耳机sync上所选的音频流。当然了，广播助手还可以用于音量控制和静音，允许用户查找、选择和控制广播音频流的播放。
在这里插入图片描述

使用广播助手和PAST

下图是手机的UI显示，它展示了如何使用手机上的APP显示和选择广播流，以及如何控制耳机的量和静音。
在这里插入图片描述

手机APP作为广播助手和音量控制的示例

虽然音频流的广播源和广播接收器之间没有连接，但设备可以使用 ACL 连接来帮助同步到 BIS。例如，家用电视使用加密的广播音频，允许房间内的多个人连接到电视。为了实现这一点，电视会包含一个广播助手，它会与每个用户的耳机配对，如下图所示。当用户选择连接到电视时，广播助手会提供有关如何使用 PAST 同步到 BIS 以及如何传输 Broadcast_Code的详细信息。
在这里插入图片描述

广播助手与BMS的搭配

使用广播助手选择广播音频流

Solicitation Requests

如果BMR要使用广播助手查找BMS，他会发送可连接广播，其中AD data会包含BASS(Broadcast Audio Scan Service)的UUID
在这里插入图片描述

Solicitation Requests流程

如上所示，BMR发送了包含 BASS 服务 UUID 的扩展广播。左侧，三个广播助手处于有效范围内。广播助手1与BMS共置，并正在主动扫描。广播助手2没有主动扫描，广播助手3正在主动扫描。在这种情况下，广播助手1和3都可以响应请求。

HCI log如下图
在这里插入图片描述

BASS AD data

广播助手连上BMR之后，广播助手需要PAC信息才能知道BMR的接收能力，才能为BMR设置适当的 BIS_Sync值，以确保其接收正确的BIS，如下图service discovery flow
在这里插入图片描述

广播助手发现BMR音频能力

除了PACS，还需要用到BASS(Broadcast Audio Scan Service),用于发现和连接广播音频流以及发送broadcast code。

BASS有两个特性，无论何时使用，这两个特性都是必需的：
在这里插入图片描述

BASS characteristic

Broadcast Audio Scan Control Point允许一个或多个广播助手通知接收者 (Acceptor) 它们是否正在主动代表接收者 (Acceptor) 查找BMS。它们可以指示接收者 (Acceptor) 如何查找 BIG、连接到 BIG、断开与 BIG 的连接，并提供 Broadcast_Code 来解密已加密的音频流。Broadcast Audio Scan Control Point中有一个非常重要的参数，即 BIS_Sync。当广播助手将其设置为 0b1 时，它会通知接收者 (Acceptor) 开始接收音频流。当将其设置为 0b0 时，接收者 (Acceptor) 应该停止接收音频流。

上一段第一行提到的“一个或多个广播助理”非常重要。Acceptor 可以使用任意数量的广播助手。只需每个广播助手都拥有指向该Acceptor的ACL链接即可。

Broadcast Audio Scan Control Point的opcode：

  • Remote Scan Stopped(0x00): 通知server, client未代表server扫描广播源。
  • Remote Scan Started(0x01): 通知server, client正在代表server扫描广播源。
  • Add Source(0x02): 请求server添加信息（包括广播源的metadata），并请求server同步到广播源发送的 PA 和/或 BIS。
  • Modify Source(0x03): 请求server更新metadata、同步或停止同步由 Source_ID 标识的广播源发送的 PA 和/或 BIS。
  • Set Broadcast_Code(0x04): 向server提供 Broadcast_Code，用于解密由 Source_ID 标识的广播源发送的 BIS。
  • Remove Source(0x05): 请求server删除由 Source_ID 标识的广播源的所有信息。

Broadcast Receive State用于揭示BMR正在执行的操作，它连接到哪个BIG、当前正在接收该 BIG 中的哪些BIS、它是否可以解密这些BIS以及它当前拥有的每个BIS的metadata。

Remote Broadcast Scanning

广播助手通过Broadcast Audio Scan Control Point的opcode：Remote Scan Started，告诉BMR，已经开始帮它扫描附近的BMS。
在这里插入图片描述

广播助手开始scan

Adding broadcast sources

广播助手通过opcode: add source操作BMR去同步哪个BIS，如下图:
在这里插入图片描述

add source

BMR收到Add source命令之后，会返回一个通知，其中PA_Sync_State是SyncInfo Request，这样广播助手就会通过PAST方式帮BMR同步周期广播

参数说明：

  • Source_ID： 由服务器分配。对于服务器公开的广播接收状态特性的每个实例，该值必须是唯一的
  • Source_Address_Type：0x00 = Public Device Address or Public Identity Address，0x01 = Random Device Address or Random (static) Identity Address
  • Source_Address：BMS address
  • Source_Adv_SID：AUX_ADV_IND PDU 的 ADI 字段的 Advertising_SID 子字段或 LL_PERIODIC_SYNC_IND 包含指向广播源发送的 PA 的 SyncInfo。
  • Broadcast_ID：BMS的Broadcast_ID
  • PA_Sync：0x00 = Do not synchronize to PA，0x01 = Synchronize to PA – PAST available，0x02 = Synchronize to PA – PAST not available
  • PA_Interval： SyncInfo field Interval parameter value
  • BIS_Sync： 要连接的 BIS_Index 值，每个bit对应一个bis index，0x00: 不同步BIS，0xFFFFFFFF: 不指定BIS，BMR根据自身audio location去同步BIS
  • Metadata： LTV格式的metadata
  • PA_Sync_State： 0x00: Not synchronized to PA，0x01: SyncInfo Request，通过PAST方式sync周期广播，0x02: Synchronized to PA，0x03: Failed to synchronize to PA，0x04: No PAST
  • BIG_Encryption：0x00: Not encrypted，0x01: Broadcast_Code required，0x02: Decrypting，0x03: Bad_Code (incorrect encryption key
  • Bad_Code：broadcast code，用于解密广播音频流
  • BIS_Sync State：0x00000000: 0b0 = Not synchronized to BIS_index[x]，0xxxxxxxxx: 0b1 = Synchronized to BIS_index[x]，0xFFFFFFFF: Failed to sync to BIG

当BMR收到add source cmd之后，state变化如下图
在这里插入图片描述

add source state

通过PAST方式同步周期广播

PAST的timing如下图：
在这里插入图片描述

Periodic Advertising Sync Transfer procedure timings

A是在发周期广播，广播间隔是PAI，B和C建立连接，连接间隔是CI，B要帮C同步上A的周期广播；
B要帮C同步周期广播，首先B自己要先同步上A发的周期广播；
假设，B收到一包广播，paEventCounter是PEb，此时，B和C的connEventCount是CEs，那么，B就可以计算出将来的某个时间点CEref，再加上offset，就是A发送周期广播PEa的时间点。
B通过cmd LL_PERIODIC_IND把这些信息发给C，如下：
在这里插入图片描述

Periodic Advertising Sync Transfer procedure timings

从上图可看出，CEref就是LL_PERIODIC_IND它自己，加上53.13ms的地方就能发现一包周期广播
在这里插入图片描述

Periodic Advertising Sync Transfer procedure timings

C收到LL_PERIODIC_IND之后，准备在CEc这个时间点接收最近的PEc，假设CEc与PEc的距离是Target, 所以，关键是算出target，C就能准确无误的接收到PEc，数学公式如下：

target = (CEref – CEc) × CI + Offset – (PEa – PEc) × PAI

当然了，由于三个设备(A,B,C)的clock不同，target并不会那么准确，需要有一个容错范围，如下：

Target ≤ Target_Tolerance < Target + U
U = 30 µs or 300, 这个值取决于 SyncInfo 的 Offset Units 字段的值

至此，C就成功同步上了A发送的周期广播。

Setting Broadcast_Codes

如果广播音频流是加密的，那几需要broadcast code来进行解密，BMR通过Broadcast Code required来请求broadcast code，flow如下
在这里插入图片描述

set broadcast code

下面通过HCI log回顾一下整个flow
在这里插入图片描述

set broadcast code

sync BIG

同步完周期广播，获取到了broadcast code，接下来就可以下HCI_LE_Create_BIG cmd给controller去sync BIG了
在这里插入图片描述

Broadcast Audio Stream synchronization

从BIGInfo里面我们可以得到BIG_Offset, BIG_Offset是Sync BIG的关键参数，如下图：
在这里插入图片描述

Sync BIG

如下图air log，BIGInfo中的BIG Offset是2.490ms，AUX_SYNC_IND这包加上这个BIG Offset就能准确无误地接收到BIS data
在这里插入图片描述

Sync BIG air log

sync上BIG之后，Broadcast Receive State也要更新
在这里插入图片描述

update sync state

以上，sync上BIG之后，建立data path就可以尽情享受广播音频了。

如果需要本文中的log，可以私聊（＾ｖ＾）

# 音视频 # 开源协议
Logo
魔乐社区

魔乐社区（Modelers.cn) 是一个中立、公益的人工智能社区，提供人工智能工具、模型、数据的托管、展示与应用协同服务，为人工智能开发及爱好者搭建开放的学习交流平台。社区通过理事会方式运作，由全产业链共同建设、共同运营、共同享有，推动国产AI生态繁荣发展。

更多推荐

cover

量化挑战赛冠军专访：4小时啃下W4A8量化，我靠的是这些经验

avatar 魔乐社区
cover

替你试过了，消费级显卡可以跑的开源文生图SOTA模型，顶级渲染、高密度文本绘图

avatar 魔乐社区
cover

「极限压缩 量化未来」Modelers GeekDay上海站圆满落幕

avatar 魔乐社区