On 19.05.2018 22:34, Attila Tőkés wrote:
Hi,
Apparently, the source based timing logic (when using the
headset_head_unit profile there is a sink and a source) from:
https://github.com/pulseaudio/pulseaudio/blob/master/src/modules/bluetooth/module-bluez5-device.c#L1581
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:
https://www.dropbox.com/s/yy7a1sltmzbsakk/bt-log-bcm.txt?dl=0
---
Using autodetect_mtu=yes resolves the delay, but the problem does not
seems to be the MTU.
What problem remains after setting autodetect_mtu=yes?
---
The issue, I think is the same as in:
[pulseaudio-discuss] [PATCH] Fix: Distorted audio during Bluetooth SCO
HFP/HSP playback
https://lists.freedesktop.org/archives/pulseaudio-discuss/2017-January/027448.html
---
The link you reference describes exactly the MTU issue. We had to revert
setting
autodetect_mtu=yes by default because there seem to be more head sets where
it does not work with autodetect_mtu = yes than those which require it.
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.cuss
The SCO protocol requires that for each packet sent by the head set one
has to be sent
back from the system to the head set. So the timing is controlled by the
head set and
it is not guaranteed that this timing matches the system clock.
Therefore you cannot
use system clock and you would probably see a delay between recording
and playback
after some time. A2DP playback is different because the head set has no
active part
in the timing of events.
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
