Re: HCI Set custom bandwidth for AuriStream SCO codec

From: "Pali Rohár" <pali.rohar@gmail.com>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: Pavel Machek <pavel@ucw.cz>,
	Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
	"linux-bluetooth@vger.kernel.org"
	<linux-bluetooth@vger.kernel.org>,
	Johan Hedberg <johan.hedberg@gmail.com>
Subject: Re: HCI Set custom bandwidth for AuriStream SCO codec
Date: Mon, 8 Jul 2019 23:06:16 +0200	[thread overview]
Message-ID: <20190708210616.x2dlnzjhnplu37bz@pali> (raw)
In-Reply-To: <E4A6E61C-DE37-4E5D-9401-71CCE4AE2419@holtmann.org>

[-- Attachment #1: Type: text/plain, Size: 4145 bytes --]

On Monday 08 July 2019 15:23:06 Marcel Holtmann wrote:
> Hi Pali,
> 
> >>>>>>> to be honest, I would rather see WBS implementation finally
> >>>>>>> reach PA before we start digging into this.
> >>>>>> 
> >>>>>> First I want to finish improving A2DP codec support in pulseaudio. Later
> >>>>>> I can look at HSP/HFP profiles. Ideally it should have modular/plugin
> >>>>>> extensible design. So the aim is that adding new codec would be very
> >>>>>> simple, without need to hack something related to mSBC/WBC, AuriStream
> >>>>>> or any other codec.
> >>>>> 
> >>>>> Well HSP don't have support for codec negotiation, but yes a modular
> >>>>> design is probably recommended.
> >>>>> 
> >>>>>> But for AuriStream I need to set custom SCO parameters as described
> >>>>>> below and currently kernel does not support it. This is why I'm asking
> >>>>>> how kernel can export for userspace configuration of SCO parameters...
> >>>>> 
> >>>>> We can always come up with socket options but we got to see the value
> >>>>> it would bring since AuriStream don't look that popular among
> >>>>> headsets, at least Ive never seem any device advertising it like
> >>>>> apt-X, etc.
> >>>> 
> >>>> Pali clearly has such device and he is willing to work on it. Surely
> >>>> that means it is popular enough to be supported...?
> >>> 
> >>> Just put AT+CSRSF=0,0,0,0,0,7 to google search and you would see that
> >>> not only I have such device...
> >>> 
> >>> So I would really would like to see that kernel finally stops blocking
> >>> usage of this AuriStream codec.
> >> 
> >> we need to figure out on how we do the kernel API to allow you this specific setting.
> > 
> > Hi Marcel! Kernel API for userspace should be simple. Just add two
> > ioctls for retrieving and setting structure with custom parameters:
> > 
> >  syncPktTypes = 0x003F
> >  bandwidth = 4000
> >  max_latency = 16
> >  voice_settings = 0x63
> >  retx_effort = 2
> > 
> > Or add more ioctls, one ioctl per parameter. There is already only ioctl
> > for voice settings and moreover it is whitelisted only for two values.
> 
> it is not that simple actually. Most profiles define a certain set of parameters and then they try to configure better settings and only fallback to a specification defined default as last resort.

Ok. I see that there is another "example" configuration for AuriStream
with just different syncPktTypes = 0x02BF and bandwidth = 3850.

So it really is not simple as it can be seen.

> >> We have kept is really simple since there was only CVSD and mSBC as of now.
> > 
> > Seems that custom codecs are already widely used, so it would be great
> > it Linux kernel allows to use also other codecs in future without need
> > to explicitly whitelist them.
> 
> This is an overstatement. I see only one custom codec being used. Unless you have heard from others. However as stated above, I think we need to provide an array of settings that are similar defined to what the HFP spec does. Then we just load the whole set into the kernel.

CVSD and mSBC are in use. IIRC specification also mandates ulaw a alaw
codecs but I have not seen it used. Has somebody tried to implement it?
I think just replacing voice_settings should be enough as encoding /
decoding should be done in bluetooth firmware / hardware.

And then there is AuriStream which based on google results it supported
by lot of headsets.

So at least 3 different codecs are widely supported by headset.

> >> I am also curious on what the assumptions are for the USB driver alternate settings are when using a different codec.
> > 
> > I did all above tests and kernel changes with USB bluetooth chip which
> > is integrated in notebook's combo bt+wifi intel minipci-e card.
> 
> Good to know. Since for mSBC in theory they need a new alternate settings that wasn’t really available.

I understood that both mSBC and AuriStream uses "transparent" mode of
transport and bluetooth chip itself does not know if it transmit mSBC or
AuriStream as it does not do any encoding...

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]