背景：
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。
