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
