GFPS扩展技术原理(七)-音频切换消息流

音频切换消息流

Seeker和Provider通过消息流来同步音频切换能力,触发连接做切换,获取或设置音频切换偏好,通知连接状态等等。为此专门定义了音频切换消息流Message Group 为0x07,Message codes如下:

MAC of Audio switch Messages

所有的从seeker发送到Provider的消息都需要加上MAC,这样Provider应答这些消息的时候也需要带上MAC:

  • Provider应答ACK的消息流格式如下:
  • Provider应答NAK的消息流格式如下:

Get capability of Audio switch

这个消息可以由audio switch provider或者seeker发送,用于查询对方是否支持audio switch,消息流格式如下:

Notify capability of Audio switch

在收到get capability of Audio switch消息之后,Seeker或者Provider需要回复这个消息,格式如下:

这里我们主要关注一下Audio switch capability flags,只有Provider发送的时候,这两个字节才有效。这两个字节是标注音频切换能力的:

  1. Bit 0 (octet 6, MSB): Audio switch state

    复制代码
    1, if Audio switch state is on
    0, otherwise
  2. Bit 1: multipoint configurability

    复制代码
    1, if the device supports multipoint and it can be switched between on and off
    0, otherwise (does not support multipoint or multipoint is always on)
  3. Bit 2: multipoint current state

    复制代码
    1, if multipoint is on
    0, otherwise
  4. Bit 3: on-head detection

    复制代码
    1, if this device supports on-head detection (even if on-head detection is turned off now)
    0, otherwise
  5. Bit 4: on-head detection current state

    复制代码
    1, if on-head detection is turned on
    0, otherwise (does not support on-head detection or on-head detection is disabled)

Set multipoint state

这个是audio switch seeker用来打开或关闭Provider multipoint功能的消息,消息流格式如下:

Set switching preference

这个是audio switch seeker用来设置Provider multipoint音频切换偏好的,消息流格式如下:

这里我们主要注意multipoint switching preference flag:

  • Bit 0 (MSB): A2DP vs A2DP (default 0)
  • Bit 1: HFP vs HFP (default 0)
  • Bit 2: A2DP vs HFP (default 0)
  • Bit 3: HFP vs A2DP (default 1)
  • Bit 4 - 7: reserved

上面表示的形式是"新profile"VS"旧profiler",如果那个bit置上0,代表不能切换,如果置上1,表示可以切换。举个例子Bit 3置上1,表示如果有HFP连接进来,那么需要从原来的A2DP切换到HFP。

Get switching preference

Seeker可以发送Get switching preference消息给Provider,主动获取音频切换偏好,消息流格式如下:

Notify switching preference

Switch active audio source (to connected device)

Audio switch Seekers 可以请求multipoint Provider在连接的设备中切换活跃音频源,消息流格式如下:

这里我们主要关注Switching active audio source event flags这个字节:

  • Bit 0 (MSB): 1 切换到当前设备, 0 切换到另外设备
  • Bit 1: 1 在切换后恢复播放, 0 反着来。注意: 恢复播放意味着Provider需要通过AVRCP发送一个PLAY notification 给Seeker,如果seeker之前的状态就是停播,那么Provider就要忽略这个标志。
  • Bit 2: 1 在切换出去的设备拒绝SCO 连接。 0 反着来。
  • Bit 3: 1 在切换出去的设备断开蓝牙连接。0 反着来.
  • Bit 4 - 7: 这几个bit保留未用.

如果Audio switch seeker已经是当前活跃音频设备了,然后又发送了switch active audio device 消息给Provider,那么Provider需要回复NAK,理由是0x04-Redundant device action。

对于LE Audio Provider,如果是被切换出去的设备,那么需要断开所有的协调集成员的连接。

Switch back (to disconnected device)

如果用户想切回原来的设备,那么可以发送如下格式消息:

需要注意的是switch back event:

  • 0x01:switch back,就是简单的切回去连接上。
  • 0x02:切回去然后恢复播放,这里有个前提就是断开的设备,在被断开前的状态也是播放状态才行,否则Provider会忽略这个标志。

Notify multipoint-switch event

audio switch Provider通知Seeker发生的切换事件,消息格式如下:

Get connection status

Seeker从Provider获取当前连接状态,消息格式如下:

Notify connection status

连接状态的改变,除了需要修改BLE广播,还有就是Provider需要通知当前使用共同accout key的连接的audio switch seeker。如果provider连接一个audio switch seeker和一个non-audio switch seeker,并且当前活跃设备是non-audio switch seeker,那么provider也要通知audio switch seeker。Provider发送给Seeker的连接状态的消息,格式如下:

这里注意一下Encrypted connection status,跟之前音频切换广播里的connection status一样:

clike 复制代码
encrypted_connection_status = connection_status_raw_data ^ AES(Key, IV)

其中:

  • clike Key = HKDF(account_key, NULL, UTF8("SASS-RRD-KEY"),16)
  • IV is concat(Session_nonce, Message_nonce)
  • connection_status_raw_data = concat(connection_state, custom_data, connected_devices)

Notify Audio switch initiated connection

这个是Seeker告诉Provider,此连接是audio switch发起的连接,消息格式如下:

Indicate in use account key

如果同一个Seeker上多个account key 账户连接着同一个Provider,那么Seeker使用如下格式消息告诉Provider当前使用哪个account key:

Provider收到消息后,通过校验MAC能够得知当前使用哪个account key。

Send custom data

活跃Audio switch Seeker能够封装音频流信息在custom data里发送给Provider,消息格式如下:

Provider收到custom data之后,会更新广播数据包含custom data。如果是multipoint Provider,它也需要使用相同的account key通知连接状态的改变给另外连接的seeker。

Set drop connection target

在 multipoint headsets, 如果想要断开的连接不是最近常用的连接,那么需要audio switch Seekers 告诉Provider需要断开哪个设备,数据格式如下:

相关推荐
SuperHeroWu712 小时前
【HarmonyOS 5】鸿蒙星闪NearLink详解
华为·蓝牙·harmonyos·nearlink·鸿蒙星闪·绿牙
byte轻骑兵6 天前
【Bluedroid】蓝牙HID DEVICE断开连接流程源码分析
android·c++·蓝牙·hid·bluedroid
jiang_bluetooth6 天前
从ellisys空口分析蓝牙耳机回连手机失败案例
智能手机·蓝牙·lmp·tws蓝牙耳机
Ronin-Lotus6 天前
嵌入式硬件篇---无线通信模块
嵌入式硬件·wifi·lora·无线通信·蓝牙·2.4g射频
byte轻骑兵6 天前
【Bluedroid】蓝牙 HID 设备服务注册流程源码解析:从初始化到 SDP 记录构建
蓝牙·hid·bluedroid
DONSEE广东东信智能读卡器6 天前
蓝牙身份证阅读器使用Uniapp调用二次开发demo
javascript·uni-app·蓝牙·身份证阅读器
jiang_bluetooth12 天前
低功耗蓝牙BLE的通信可靠性分析
蓝牙·低功耗蓝牙·ble
万户猴18 天前
【Android蓝牙开发实战-11】蓝牙BLE多连接机制全解析1
android·蓝牙
万户猴19 天前
【 Android蓝牙-十】Android各版本蓝牙行为变化与兼容性指南
android·蓝牙
万户猴20 天前
【Android蓝牙开发实战-9】高效处理蓝牙断开连接
蓝牙