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.
