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. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 868 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20180914/0dbff17a/attachment.sig>
