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

[Georg Chini]

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.