* Is BT_VOICE_TRANSPARENT correctly defined?
@ 2019-05-19 10:18 Pali Rohár
2019-06-07 12:59 ` Pali Rohár
0 siblings, 1 reply; 6+ messages in thread
From: Pali Rohár @ 2019-05-19 10:18 UTC (permalink / raw)
To: linux-bluetooth
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Is BT_VOICE_TRANSPARENT correctly defined?
2019-05-19 10:18 Is BT_VOICE_TRANSPARENT correctly defined? Pali Rohár
@ 2019-06-07 12:59 ` Pali Rohár
2019-06-07 15:03 ` Luiz Augusto von Dentz
0 siblings, 1 reply; 6+ messages in thread
From: Pali Rohár @ 2019-06-07 12:59 UTC (permalink / raw)
To: linux-bluetooth
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Is BT_VOICE_TRANSPARENT correctly defined?
2019-06-07 12:59 ` Pali Rohár
@ 2019-06-07 15:03 ` Luiz Augusto von Dentz
2019-06-07 15:29 ` Pali Rohár
0 siblings, 1 reply; 6+ messages in thread
From: Luiz Augusto von Dentz @ 2019-06-07 15:03 UTC (permalink / raw)
To: Pali Rohár; +Cc: linux-bluetooth@vger.kernel.org
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Is BT_VOICE_TRANSPARENT correctly defined?
2019-06-07 15:03 ` Luiz Augusto von Dentz
@ 2019-06-07 15:29 ` Pali Rohár
2019-10-14 11:07 ` Pali Rohár
0 siblings, 1 reply; 6+ messages in thread
From: Pali Rohár @ 2019-06-07 15:29 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth@vger.kernel.org
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Is BT_VOICE_TRANSPARENT correctly defined?
2019-06-07 15:29 ` Pali Rohár
@ 2019-10-14 11:07 ` Pali Rohár
2019-10-16 18:57 ` Marcel Holtmann
0 siblings, 1 reply; 6+ messages in thread
From: Pali Rohár @ 2019-10-14 11:07 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth@vger.kernel.org
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Is BT_VOICE_TRANSPARENT correctly defined?
2019-10-14 11:07 ` Pali Rohár
@ 2019-10-16 18:57 ` Marcel Holtmann
0 siblings, 0 replies; 6+ messages in thread
From: Marcel Holtmann @ 2019-10-16 18:57 UTC (permalink / raw)
To: Pali Rohár; +Cc: Luiz Augusto von Dentz, linux-bluetooth@vger.kernel.org
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-10-16 18:57 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-05-19 10:18 Is BT_VOICE_TRANSPARENT correctly defined? Pali Rohár
2019-06-07 12:59 ` Pali Rohár
2019-06-07 15:03 ` Luiz Augusto von Dentz
2019-06-07 15:29 ` Pali Rohár
2019-10-14 11:07 ` Pali Rohár
2019-10-16 18:57 ` Marcel Holtmann
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).