Hi all,
PulseAudio recently started to use
getsockopt(sock, SOL_SCO, SCO_OPTIONS, &sco_opt, &len);
read_mtu = sco_opt.mtu;
write_mtu = sco_opt.mtu;
to query the MTU of the SCO socket. Previously we used a fixed value of
48, but that didn't work for some bluetooth chipsets (see the commit
message[1]). Now, however, it was reported[2] that the new code doesn't
work on some hardware where the old fixed MTU used to work.
What is PulseAudio expected to do? We will have to add an option for
configuring the MTU for now, but that's not a real solution, because
users can't be expected to figure out that they need to fiddle with the
MTU if HSP audio doesn't work. Is this a kernel bug? When this new code
in PulseAudio gets more widely used and starts breaking people's
bluetooth audio, should I tell the users to send bug reports to this
mailing list? Or should PulseAudio keep using a fixed MTU, unless
configured otherwise?
[1] https://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=fb6b8dfdec2df39c055f98266aa1eb75e8ebfb1c
[2] https://lists.freedesktop.org/archives/pulseaudio-discuss/2017-January/027408.html
--
Tanu
https://www.patreon.com/tanuk
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
