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

[Arun Raghavan]

On Sat, 16 Sep 2017, at 12:11 AM, Georg Chini wrote:
> On 14.09.2017 18:47, Tanu Kaskinen wrote:
> > On Wed, 2017-09-13 at 09:31 +0530, Arun Raghavan wrote:
> >> On Tue, 31 Jan 2017, at 06:48 PM, Tanu Kaskinen wrote:
> >>> On Mon, 2017-01-30 at 17:28 +0100, Georg Chini wrote:
> >>>> On 27.01.2017 21:40, Georg Chini wrote:
> >>>>> On 03.01.2017 18:17, Tanu Kaskinen wrote:
> >>>>>> On Thu, 2016-12-15 at 12:34 +0530, Renjith Thomas wrote:
> >>>>>>> Issue: When HFP/HSP profile is used with certain BT chipsets, the
> >>>>>>> audio sounds heavily distorted, with very slow playback full of noise.
> >>>>>>> During recording, the samples are dropped and it distorts the recorded
> >>>>>>> audio samples.
> >>>>>>>
> >>>>>>> The root cause of both the issues are related to the fixed MTU sizes
> >>>>>>> in the PA stack, which is 48 bytes. Here, the BT chipset CC256x had
> >>>>>>> 180 bytes MTU and it was being under-utilized and the rate at which
> >>>>>>> the samples were being accepted where not matching the expected rate,
> >>>>>>> and hence the distortion.
> >>>>>>>
> >>>>>>> Solution: The appropriate solution to this problem is by reading the
> >>>>>>> MTU size of the SCO socket using getsockopts dynamically.
> >>>>>>>
> >>>>>>> BugLink: http://bit.ly/2gDpGPv
> >>>>>>> BugLink: http://bit.ly/2hQsARK
> >>>>>>> ---
> >>>>>>>    src/modules/bluetooth/backend-native.c | 28
> >>>>>>> ++++++++++++++++++----------
> >>>>>>>    1 file changed, 18 insertions(+), 10 deletions(-)
> >>>>>> Thanks! Applied to the "next" branch.
> >>>>>>
> >>>>> Hi,
> >>>>>
> >>>>> this patch breaks HSP for me. My headset (Plantonics Backbeat Pro)
> >>>>> returns an MTU of 64, but it looks like this is only working for
> >>>>> recording.
> >>>>> When I try to play back something, I cannot hear any sound and the
> >>>>> headset disconnects after a few seconds.
> >>>>>
> >>>>> When I set omtu to 48, everything is working again.
> >>>> Tested a second headset - same result. The headset returns 64 as MTU
> >>>> but only works if I set omtu to 48. Should the patch be reverted or modified
> >>>> to change only imtu? Can anyone else confirm my problem?
> >>> I understood the commit message so that Renjith had problems in both
> >>> directions, so changing only imtu doesn't look like a good solution.
> >>>
> >>> I started a thread about this on linux-bluetooth:
> >>> https://marc.info/?l=linux-bluetooth&m=148586767818913&w=2
> >>>
> >>> If no better solutions appear, I think it's best to use 48 as the MTUs
> >>> by default, and allow using the getsockopt() method via a module
> >>> argument.
> >> Looks like this slipped between the cracks. The breakage by not having a
> >> fixed MTU seems a lot larger than the reverse. I've sent a patch to make
> >> autodetection off by default, and I guess we should re-awaken the thread
> >> on the bluez list.
> > Note that even though I wrote "it's best to use 48 as the MTUs by
> > default" in the quoted mail, I changed my mind later. The choice of
> > enabling the autodetection was deliberate. The rationale is that we
> > have two bad alternatives:
> >
> > 1) Enable autodetection by default, which will cause regressions. As
> > the reports come in, the kernel should get fixed. Eventually all
> > hardware should work out of the box.
> >
> > 2) Don't enable autodetection by default. The kernel won't get fixed,
> > and hardware that requires different MTUs than 48 will never work out
> > of the box.
> >
> > To me option 1 seems worse in the long term, but if you feel
> > differently, I'm ok with going with option 2.
> >
> The view that the kernel will get fixed is very optimistic in my
> opinion. We already had a few cases and to my knowledge
> nothing has been fixed so far. People will just disable mtu
> autodetection and that's it.
> 
> So I am fine with keeping the option disabled by default.

Rather than break things directly, I would:

1. Get buy-in from BlueZ folks about actually fixing this stuff

2. Get a clear set of instructions for users to report problems in a way
that it would be actionable to fix

3. Make this off by default for a couple of releases with a call for
people to test manually

4. Then, make it on by default

-- Arun