[pulseaudio-discuss] Bluetooth - HSP / HFP - source based timing & hard-coded MTU causes SCO packets to be badly delayed

Attila Tőkés attitokes at gmail.com
Sat May 19 20:34:14 UTC 2018


Apparently, the source based timing logic (when using the headset_head_unit
profile there is a sink and a source) from:

combined with the hard-coded MTU of 48 bytes / packet can cause SCO packets
to be badly delayed with some devices.

For example, the following happens with the CYW43438 chip used in the
Raspberry Pi 3:

PulseAudio (hard-coded) MTU - 48 bytes / packet

Real MTU - 64 bytes / packet

Packet Size negotiated at the eSCO connect - 60 bytes / packet

The CYW43438 uses the negotiated packet size of 60 bytes / packet, so it
sends bigger, 60 bytes SCO packets less often.

Based on the above logic from module-bluez5-device.c, PulseAudio sends SCO
packets (one at a time) only when SCO packet are received from CYW43438.
Because of the packet size of 60 bytes, these packets are sent less often
than PulseAudio would need to send its 48 byte packets.

The result is that the playback (paplay) is way to slow: 12.16 seconds,
instead of 9.72 seconds (+25%).

HCI (+SCO) log:


Using autodetect_mtu=yes resolves the delay, but the problem does not seems
to be the MTU.


The issue, I think is the same as in:

[pulseaudio-discuss] [PATCH] Fix: Distorted audio during Bluetooth SCO
HFP/HSP playback



I tried to change module-bluez5-device.c to always use system clock based
timing (as for A2DP) and this seems to fix the problem.

What is the reason to use this source based timing, instead of using system
clock based timing as for A2DP ? It's just optimization? Or it is some
requirement of the Bluetooth spec? Using the system clock would be more
reliable, I think.

Attila Tőkés
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20180519/40e59373/attachment.html>

More information about the pulseaudio-discuss mailing list