背景：

LE audio还没有大规模应用，但是在一些场景中需要进行大容量快速传输，例如遥控器语音传输用于语音指令识别，需要直接利用le传输pcm音频流。在此既是要求对延迟比较宽松，另外是考虑le功耗较低本质既是传输事件交互机制，所以持续的传输必然导致功耗的提升。

本文在此探讨一些对传输速率的影响因素：

透传pcm没有经过压缩的数据对速率要求较大，影响传输速率的主要因素：

1、连接间隔

cp.interval_min cp.interval_max

明显，如果这个连接间隔时间越短，那么传输的速度就增大。连接上传完数据后，蓝牙基带即进入休眠状态，保证低功耗。其是1.25毫秒一个单位。

按照le规范，链接间隔最低设置7.25ms。

2、从设备延迟或者从设备时延

cp.slave_latency

允许Slave（从设备）在没有数据要发的情况下，跳过一定数目的连接事件，在这些连接事件中不必回复Master（主设备）的包，这样就能更加省电（范围可以是0~499）。

Slave Latency = OFF时，master发包，slave必须回复，如果不回复，Master就会认为slave那边接收不正常。

减少或者设置为0，那么每次连接事件中都需要回复Master的包，当然功耗会上升，但数据发送速度也会提高。

3、数据包大小

主要受到mtu设置影响，目前le最大可设512.另外还会和主机端相关，看主机端支持的最大mtu是多少，协商机制会取两者较小者。

4、使用2M PHY 目前BLE支持3种LE PHY，分别是LE 1M PHY，LE 2M PHY，LE CODED PHY，其中LE 2M PHY用于高速率,，而理论距离是LE 1M PHY的一半，而LE CODED PHY用于长距离模式，LE 1M PHY兼顾了距离和速率，可以根据自己实际需要进行选择，如果对传输距离有要求，需要谨慎选择。

LE PHY 可以通过调用api接口发起更新，一般在peripheral端，收到ble_evt_connected事件的时候进行请求更新。如下所示，即可配置为只支持2M 的PHY：

#if (dg_configBLE_2MBIT_PHY == 1)         /* Switch to 2Mbit PHY during SUOTA */         ble_gap_phy_set(evt->conn_idx, BLE_GAP_PHY_PREF_2M, BLE_GAP_PHY_PREF_2M); #endif /* (dg_configBLE_2MBIT_PHY == 1) */

5、发送选择

要获取最大数据吞吐能力，可以将写操作属性设置为不需要ACK，即Write withoutACK，此时IFS以及接受和发送的时间都将极大优化，

在此使用notify不需要答复的方式进行通讯。

6、压缩传输数据

ADPCM编码

这是一种将pcm编码压缩的算法，主要原理是取位深差异。

音频信号虽然是比较连续性的，有些差值比较小，有些差值比较大，如果差值比较大有可能用4bit表示不了，如果增大表示差值的位数（例如8bit\16bit）是可以解决这个问题，但就导致数据量变大，没起到压缩的目的，而且这种差值比较大的只是少数，大部分还是差值比较小的。

为了解决这个问题，前辈们就想出了ADPCM，定义一个因子，用差值除以因子的值来表示两点之差，如果两点之间差值比较大，则因子也比较大。通过因子引入，可以使得DPCM编码自动适应差值比较大的数据。

ADPCM算法并没用固定标准，最经典的就是IMA ADP。

四、

传输过程不仅需要考虑传输带来的速率要求，另外也需要考虑处理过程延时，DMA读取经过采样的pcm给到buf是比较快的，这里为了避免buf重新覆盖采用了两个buf交替传输。

如果这里需要加压缩算法还需要考虑加深buff。