Is BT_VOICE_TRANSPARENT correctly defined?

Is BT_VOICE_TRANSPARENT correctly defined?

[Pali Rohár]

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

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.

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

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

Re: Is BT_VOICE_TRANSPARENT correctly defined?

[Pali Rohár]

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?

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

Re: Is BT_VOICE_TRANSPARENT correctly defined?

[Luiz Augusto von Dentz]

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

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.

-- 
Luiz Augusto von Dentz

Re: Is BT_VOICE_TRANSPARENT correctly defined?

[Pali Rohár]

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

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.

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

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

Re: Is BT_VOICE_TRANSPARENT correctly defined?

[Pali Rohár]

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

Re: Is BT_VOICE_TRANSPARENT correctly defined?

[Marcel Holtmann]

Hi Pali,

>>>>> 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...

so I do not recall why that has been chosen this way. Does it work any better if you chose a different value. I mean the air codec is transparent and so the input to the PCM interface must be treated transparent as well. Meaning whatever value you have for the other settings doesn’t matter.

However I did check the specs and can’t find any note in that direction. However we are feeding mSBC frames instead of PCM frames in the case of CVSD into the controller. So it should just work with whatever values the voice setting has.

Regards

Marcel