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. Cheers, Arun
