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. -- Tanu https://www.patreon.com/tanuk
