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

[Arun Raghavan]

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