TI中文支持网根据该文dev.ti.com/…/ble_voice.html
1.除了BLE报文中的用户数据，会携带ATT L2CAP头等信息，带来额外开销。文中下表第一行 7=4B L2CAP header + 3B ATT header，第二行的21是如何计算出来的？
2. 10ms秒建一次连接，每次发3-5个notification，是能够满足文中计算的传音频需要的吞吐量的。10ms 3-5个notification没有考虑ios连接间隔的限制，和丢包的问题。如果丢包可能导致音频压缩无法解决等问题，是否要加ARQ重传等机制？
| Data | Calculation | rate |
|---|---|---|
| L2CAP and ATT header | (7 * 5) B / 12ms | 23.33kbps |
| Complete packets overhead | (21 * 5) B / 12ms | 70kpbs |
Viki Shi：
这个问题比较底层了，我跟同事讨论一下，会尽快上来po更新
Viki Shi：
回复 Viki Shi:
请问你的应用吞吐量是不是基于7 字节的header及20 字节的应用数据？
Kaifei Pu：
回复 Viki Shi:
是的。蓝牙4.1之前的协议MTU不能扩展，去掉header之后是20字节。
这里是在看dev.ti.com上的教程，有一些疑问：
1.问题中截图的21字节是如何计算的
2.第二个问题已有答案，蓝牙4.1 1Mbps的可以满足16k的采样，可以采用sbc压缩，理论上不会丢数据，但实际可能受到干扰或其他，丢数据也很少，可以忽略，也不影响解码。
