On 14/09/2018 16:42, Luiz Augusto von Dentz wrote:
>> I propose to use 76 bitpool as a default maximum (454.8 kbps for Joint 
>> Stereo, 44.1 kHz, 8 subbands, 16 blocks). This bitpool is optimal for both 
>> EDR 2 mbit/s and EDR 3 mbit/s modes, since it packs audio frames with least 
>> wasted bytes possible.
>> EDR 2 mbit/s: up to 4 audio frames, 11.7 ms, 2 wasted bytes
>> EDR 3 mbit/s: up to 6 audio frames, 17.5 ms, 14 wasted bytes.
> That is a bit too hight I would say, and not sure if there would be
> any headset to make use of it.

This bitrate utilizes 2-DH5 and 3-DH5 packet types (the most common ones for 
audio streaming) as optimally as possible.

2-DH5 maximum payload size is 679 bytes. With bitpool 64, you can fill the 
packet with 4 audio frames (11.7 ms), which will take 564 bytes, and 98 bytes 
are wasted (679 - 12 L2CAP header - 4 RTP header - 1 SBC header). With bitpool 
76, you can fill the packet with the same 4 audio frames and 11.7 ms audio, but 
it will take 660 bytes, and only 2 bytes are wasted.

Bluetooth uses TDMA and transfers DH5 packets in 3.75 ms. You won't get higher 
packet rate or higher reliability if you send packets with less data than the 
packet can possible contain.

There are some headsets with higher or unlimited bitpool value:

Beats Solo³: bitpool 2..250
AirPods: bitpool 2..250
JBL Everest Elite 750NC: bitpool 10..80

>
>> Note that Pulseaudio/bluez (not sure which) does not manage L2CAP MTU 
>> correctly. For EDR 2 mbit/s, MTU should be set to 679 (ignoring higher 
>> values upon negotiation), and EDR 3 mbit/s should use 1021 (right now 
>> something like 800 is used).
> We could do that if we know the packet type used by the link but that
> is not how it is currently done in BlueZ, we always use L2CAP default
> in case the socket don't set it:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/tree/include/net/bluetooth/l2cap.h#n34
>
> Where did you get these values from btw?

These are max payload sizes for 2-DH5 and 3-DH5
http://www.osted.dk/bluetooth/bt_transfer_rate.html
It's reasonable to use these values as an MTU to prevent packet fragmentation 
on a lower levels.
Android does that.



Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Reply via email to