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
[email protected]
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
[email protected]
Hi Pali,
On Fri, Jun 7, 2019 at 4:43 PM Pali Rohár <[email protected]> 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
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 <[email protected]> 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
[email protected]
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 <[email protected]> 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
[email protected]
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