Re: Is BT_VOICE_TRANSPARENT correctly defined?

["Pali Rohár" <pali.rohar@gmail.com>]

On Friday 07 June 2019 17:29:15 Pali Rohár wrote:
> On Friday 07 June 2019 18:03:50 Luiz Augusto von Dentz wrote:
> > Hi Pali,
> > 
> > On Fri, Jun 7, 2019 at 4:43 PM Pali Rohár <pali.rohar@gmail.com> wrote:
> > >
> > > On Sunday 19 May 2019 12:18:54 Pali Rohár wrote:
> > > > Hello!
> > > >
> > > > Now I'm looking at BT_VOICE_TRANSPARENT definition which comes from file
> > > > include/net/bluetooth/bluetooth.h and it has value 0x0003. It is really
> > > > correct? Because it means following format:
> > > >
> > > >   Linear Coding, 8-bit without padding bits, 1's complement
> > > >
> > > > I think that usage of 1's complement is not easy as there is no C type
> > > > which matches it. Should not it be 2's complement or rather Unsigned
> > > > type?
> > > >
> > > > Seems that main usage of BT_VOICE_TRANSPARENT is mSBC codec and I doubt
> > > > that it uses 1's complement signed format (specially as it should be
> > > > modification of SBC codec which encode bytes as unsigned type).
> > > >
> > > > There is another define BT_VOICE_CVSD_16BIT with value 0x0060 which
> > > > seems to be correct as it means Linear Coding, 16-bit without padding
> > > > bits, 2's complement and encoded by CVSD codec.
> > >
> > > Hello, can somebody look at this BT_VOICE_TRANSPARENT definition and
> > > verify that it really should be defined as unsigned or 2's complement?
> > 
> > Are you talking about these:
> > 
> > https://elixir.bootlin.com/linux/latest/source/include/net/bluetooth/bluetooth.h#L119
> 
> Yes, exactly.
> 
> > Which is used in ofono:
> > 
> > https://github.com/DynamicDevices/ofono/blob/master/src/handsfree-audio.c#L93
> > 
> > Afaik these values work as intended with mSBC/WBS.
> 
> And I suspect that definition is wrong. mSBC does not use 1's complement
> format.

Any comments on this? Could either somebody confirm or not if current
defined constant BT_VOICE_TRANSPARENT is correct? In previous emails I
wrote why I think it is defined incorrectly...

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