LE Audio 蓝牙协议规范(1)--LE 状态

>
在思考,通过怎么样的角度能够深入浅出的弄清楚LE audio spec相关的内容。
不断总结,不断完善自己的知识结构体系
按照自己的理解,整理一下ble audio 相关的知识点# 系列文章目录


LE Audio 蓝牙协议规范(1)--ble状态

前言

状态是从宏观角度了解ble,spec将状态分为划分为7种状态,这些状态又可以分属于非连接状态和连接状态 。
不同状态下,链路层都会有对应的PDU格式定义,不同的PDU对应不同的物理信道,这些知识点可以继续衍生
首先了解这些状态之间的切换,对于后面深入分析整个LE audio 流程十分必要


一、ble audio中需要关注哪些状态?

ble audio分为两种方式,一个是通过GATT连接(UMS和UMR),一个是通过ble 广播包(BMS和BMR)。
需要建立连接的GATT需要关注initiating 和 connection state
非连接广播包需要关注 Advertising,Scanning,Isochronous Broadcasting state,Synchronization state
基本上所有状态都会涉及到ble audio的应用场景。

二、状态详解

在这里插入图片描述

1.Standby state

ble 默认状态,当controller power on之后,自动进入到standby状态,并且所有其他状态退出之后,都会回到该状态

2.Advertising state

在广播态的时候Link Layer 会发送advertising PDU。
在这个状态下有两种事件:

  • advertising event 广播事件
  • periodic advertising events 周期广播事件

两种event 都是由一个或多个advertising PDU组成

  • advertising event 可以根据connectable 和scannable,direct 等等差异分为七种不同的类型,每种类型都有不同的应用场景, 不在此赘述

  • Periodic advertising 简称 PA, 同样使用advertising PDU在 广播信道发送数据,并不是完全等价于普通ble adv,是core spec5.2 引入的新内容,作为ble audio的重要知识点,会有其他章节详细介绍,在此处做个简单了解

3.Scanning state

与广播态对应的是scanning 状态,LL会在ble 广播信道监听周围设备或指定设备发送的广播包。
Host可以配置一些过滤条件,controller会根据这些配置,过滤掉不需要的广播包,将感兴趣的广播包上报。
分为两种scan状态类型:

  • Passive scanning
    在这种状态下,controller只监听,不发送任何其他包,并且将监听到的广播包直接上报给host
  • Active scanning
    controller除了监听,可能还会回复scan request给 advertiser,要求获得更多的信息,并且host会在收到adv report 和scan rsp之后,打包一起往上层app送,普遍采用此种类型

4.Initiating state

在这个状态,LL 同样会在ble 广播信道监听设备,并且在发现感兴趣设备之后,会发送connection request,从而切换到连接状态

5.Synchronization state

在同步状态,LL需要监听有规律的广播,而这种广播分为两种类型:

  • periodic advertising trains 周期广播队列
  • broadcast isochronous streams (BIS)

这个状态的重点是去监听,然后使自己能够同步到这些固定间隔的广播序列中,从而能够获取到完整的信息

6.Isochronous Broadcasting state

在等时广播状态,LL 需要能够发送BIS PDUs,
多个BISes可以组成一个BIG,一个BIG最多包含31个BISes。
每个BIS都是携带数据的子单元。
Host 产生的数据SDU可以被拆分,重新组包成多个BIS PDU,spec都有做一些详细的规定。
这个状态的重点是发送BIS ,相对于上一个状态中的对立面

7.CONNECTION STATE

从发起状态切换而来。
这个状态下,LL 会在数据信道(Data Physical Channel)进行一些数据的交互。
定义了master和salve两种角色,与ble audio 相关的CIS ,CIG等等。
这个状态也是core spec 最开始引入的几个基本概念,不做过多解读


总结

虽说LE audio在七种状态都有涉及,但是我们需要特别关注advertising,Synchronization state,Isochronous Broadcasting state这几种状态,在core5.2 中,对support LE audio 都有很多新增内容,后续将继续展开

  • 1
    点赞
  • 12
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
ble audio补丁原理是利用hidraw节点捕捉协议栈发送的语音数据,目前Android Blueroid将ble语音数据和按键信息通过hid发送出去,通过建立hidraw节点,可以从中捕捉到语音数据。目前通过ble hal实现从hidraw中读取遥控器语音数据,在Android框架层上就通过配置文件将ble hal导入到音频框架中,并通过绑定Android原生已有的耳麦设备来完成audio音频策略选择,通过apk检测ble连接状态,通知audio服务耳麦设备的状态就可以使得录音通路切换至ble hal,实现从ble获取录音数据功能。 打补丁前最好使用干净的环境,不要有别家方案ble补丁,否则可能会有不兼容问题。 补丁如若不能使用首先检查节点是否存在和其权限,正常节点权限如下: ls -l /dev/hidraw* crw-rw---- 1 system audio 241, 0 2018-12-18 13:42 /dev/hidraw0 audio用户组有读写权限。 2、如果selinux模式为Enforcing,可以通过logcat搜索avc关键字。有如下类似提示则为异常,提示进程没有权限,检查sepolicy是否设置正常: avc: denied { read } for name="/" dev="tmpfs" ino=6145 scontext=u:r:mediaserver:s0 tcontext=u:object_r:device:s0 tclass=dir permissive=0 //Android 5.0和6.0版本,audio hal被mediaserver进程加载 avc: denied { read } for name="/" dev="tmpfs" ino=8125 scontext=u:r:audioserver:s0 tcontext=u:object_r:device:s0 tclass=dir permissive=0 //Android 7.0版本,audio hal被audioserver进程加载 avc: denied { read } for name="hidraw" dev="sysfs" ino=16332 scontext=u:r:hal_audio_default:s0 tcontext=u:object_r:sysfs:s0 tclass=dir permissive=0 //Android 8.0和9.0版本,audio hal被android.hardware.audio@2.0-service进程加载 3、检查audio的配置,打上patch后,首先确认小机上文件是否有修改到,目前文件可能位于/vendor/etc或/system/etc目录下,其中/vendor/etc下的配置文件是优先解析的。确保文件无误后,通过dumpsys media.audio_policy查看ble hal是否正常加载。 以下是相关说明: AudioPolicyManager: 0xf20c5200 Command Thread: 0xf20af140 Tones Thread: 0xf20af020 ... - Available input devices: Device 1: - id: 3 - type: AUDIO_DEVICE_IN_BUILTIN_MIC - Profiles: Profile 0: - format: AUDIO_FORMAT_PCM_16_BIT - sampling rates:8000, 11025, 12000, 16000, 22050, 24000, 32000, 44100, 48000 - channel masks:0x000c, 0x0010 Device 2: - id: 20 - type: AUDIO_DEVICE_IN_WIRED_HEADSET //对应的数值是0x80000010 - name: RemoteDM1204 - Profiles: Available input devices指示当前可用设备,目前ble hal是和AUDIO_DEVICE_IN_WIRED_HEADSET设备绑定,如果需要录音走ble hal,AUDIO_DEVICE_IN_WIRED_HEADSET设备必须出现在可用设备中,如果没有,就可能是补丁中hidaudio.apk的问题。 HW Modules dump: ... - H
蓝牙核心规范(v5.4)11.1-le audio 笔记是蓝牙技术在音频传输领域的重要突破,它为音频设备之间的无线通信提供了更好的解决方案。要了解其诞生的前世今生,需要从蓝牙技术的发展历程和音频传输的需求出发。 蓝牙技术最初是由瑞典的爱立信公司于1994年提出的,主要用于在移动设备之间进行短距离的无线通信。起初,蓝牙技术主要应用于数据传输,例如手机与耳机之间的通信。随着技术的不断进步,人们对音频传输的需求越来越大,这促使了蓝牙技术在音频领域的拓展。 在过去的版本中,蓝牙技术在音频传输上还存在一些问题,如传输质量不稳定、延迟较高等。为了解决这些问题,蓝牙核心规范(v5.4)11.1-le audio 笔记于20xx年发布,它是蓝牙技术在音频传输上的一次重要突破。 11.1-le audio 是指针对低功耗设备的音频传输规范。它采用了新的音频编解码算法和协议,能够在保证音质的同时,降低能耗和延迟。这使得蓝牙设备可以更好地支持高品质音频的传输,例如无线耳机、扬声器和音响等。 此外,11.1-le audio 还具备一些其他的优势。它支持多路音频传输,可以同时连接多个音频设备,实现多播功能。同时,它还具备较高的兼容性,可以与之前版本的蓝牙技术进行互操作。 总的来说,蓝牙核心规范(v5.4)11.1-le audio 笔记的诞生是蓝牙技术在音频传输领域的一次重要进步。它解决了以往版本在音质、能耗和兼容性等方面的不足,并且为音频设备之间的无线通信提供了更好的解决方案。作为蓝牙技术的一个重要分支,它对于无线音频设备的发展和普及具有积极的推动作用。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值