Default to HW mSBC on capable controllers ?

Default to HW mSBC on capable controllers ?

[Joakim Tjernlund]

There seems to be quite a few USB controllers gaining the BTUSB_WIDEBAND_SPEECH which I guess means HW mSBC but currently there is no way to select this mode.
Any idea if one could patch the kernel to default to HW mSBC and user apps like bluealsa/pulseaudio would just use it automatically?

Re: Default to HW mSBC on capable controllers ?

[Luiz Augusto von Dentz]

Hi Joakim,

On Fri, Dec 18, 2020 at 10:48 AM Joakim Tjernlund
<Joakim.Tjernlund@infinera.com> wrote:
>
> There seems to be quite a few USB controllers gaining the BTUSB_WIDEBAND_SPEECH which I guess means HW mSBC but currently there is no way to select this mode.
> Any idea if one could patch the kernel to default to HW mSBC and user apps like bluealsa/pulseaudio would just use it automatically?

It is in our plan to support HW offloading, but that doesn't mean all
platforms will be supported since that depends on the PCM lines being
connected to BT controller in the first place.

-- 
Luiz Augusto von Dentz

Re: Default to HW mSBC on capable controllers ?

[Joakim Tjernlund]

On Fri, 2020-12-18 at 11:43 -0800, Luiz Augusto von Dentz wrote:
> Hi Joakim,
> 
> On Fri, Dec 18, 2020 at 10:48 AM Joakim Tjernlund
> <Joakim.Tjernlund@infinera.com> wrote:
> > 
> > There seems to be quite a few USB controllers gaining the BTUSB_WIDEBAND_SPEECH which I guess means HW mSBC but currently there is no way to select this mode.
> > Any idea if one could patch the kernel to default to HW mSBC and user apps like bluealsa/pulseaudio would just use it automatically?
> 
> It is in our plan to support HW offloading, but that doesn't mean all
> platforms will be supported since that depends on the PCM lines being
> connected to BT controller in the first place.

Yes, but it would be nice if one could test that easily now, a patch for
enabling HW mSBC. You don't need to apply it upstream yet though.

 Jocke

Re: Default to HW mSBC on capable controllers ?

[Pali Rohár]

On Friday 18 December 2020 13:32:29 Joakim Tjernlund wrote:
> There seems to be quite a few USB controllers gaining the BTUSB_WIDEBAND_SPEECH which I guess means HW mSBC

No, it does not mean mSBC.

If you want to query if your bluetooth adapter supports hw mSBC then you
need to check OCF_READ_LOCAL_CODECS command. You can look into script
sco_features.pl for details.

Note that currently it is not possible to send OCF_READ_LOCAL_CODECS
command from non-root user as kernel currently does not allow it.

> but currently there is no way to select this mode.

Yes. "/bin/hciconfig voice" allows to set only voice settings for old
Add Synchronous Connection HCI command which does not support hw mSCB.

> Any idea if one could patch the kernel to default to HW mSBC and user apps like bluealsa/pulseaudio would just use it automatically?

For usage mSBC hw encoder you need to use Enhanced Setup Synchronous
Connection HCI command for establishing SCO connection.

For using HW encoder you need to stop feeding socket with mSBC encoded
data and instead put into this socket RAW pcm samples. Also you need
somehow inform kernel about this change.

For both things I designed new setsockopt() API which I described in:
https://lore.kernel.org/linux-bluetooth/20200419234937.4zozkqgpt557m3o6@pali/

Re: Default to HW mSBC on capable controllers ?

[Pali Rohár]

On Friday 18 December 2020 11:43:32 Luiz Augusto von Dentz wrote:
> Hi Joakim,
> 
> On Fri, Dec 18, 2020 at 10:48 AM Joakim Tjernlund
> <Joakim.Tjernlund@infinera.com> wrote:
> >
> > There seems to be quite a few USB controllers gaining the BTUSB_WIDEBAND_SPEECH which I guess means HW mSBC but currently there is no way to select this mode.
> > Any idea if one could patch the kernel to default to HW mSBC and user apps like bluealsa/pulseaudio would just use it automatically?
> 
> It is in our plan to support HW offloading, but that doesn't mean all
> platforms will be supported since that depends on the PCM lines being
> connected to BT controller in the first place.

Dedicated PCM lines are used in embedded world and maybe also still in
some mobile segment. I remember that e.g. Nokia N900 had this setup. And
it was quite crazy how it was finally configured... but it worked!

But this is nothing for classic x86 laptops with USB bluetooth
controllers on classic intel bluetooth+wifi mPCIe cards where SCO
traffic is routed via HCI (over USB). And not via dedicated PCM pins.
Moreover I think there are not any mainstream laptop which have PCM pins
on mPCIe slots usable for such bluetooth mPCIe cards.

For classic desktop / laptop it is needed to deal with fact that SCO
audio is routed via HCI (like A2DP) and therefore support for Enhanced
Setup Synchronous Connection HCI command.

AFAIK even for routing SCO over PCM when mSBC hw encoder is used,
Enhanced Setup Synchronous Connection HCI command is required.

Re: Default to HW mSBC on capable controllers ?

[Luiz Augusto von Dentz]

Hi Pali,

On Mon, Dec 21, 2020 at 1:14 PM Pali Rohár <pali@kernel.org> wrote:
>
> On Friday 18 December 2020 11:43:32 Luiz Augusto von Dentz wrote:
> > Hi Joakim,
> >
> > On Fri, Dec 18, 2020 at 10:48 AM Joakim Tjernlund
> > <Joakim.Tjernlund@infinera.com> wrote:
> > >
> > > There seems to be quite a few USB controllers gaining the BTUSB_WIDEBAND_SPEECH which I guess means HW mSBC but currently there is no way to select this mode.
> > > Any idea if one could patch the kernel to default to HW mSBC and user apps like bluealsa/pulseaudio would just use it automatically?
> >
> > It is in our plan to support HW offloading, but that doesn't mean all
> > platforms will be supported since that depends on the PCM lines being
> > connected to BT controller in the first place.
>
> Dedicated PCM lines are used in embedded world and maybe also still in
> some mobile segment. I remember that e.g. Nokia N900 had this setup. And
> it was quite crazy how it was finally configured... but it worked!
>
> But this is nothing for classic x86 laptops with USB bluetooth
> controllers on classic intel bluetooth+wifi mPCIe cards where SCO
> traffic is routed via HCI (over USB). And not via dedicated PCM pins.
> Moreover I think there are not any mainstream laptop which have PCM pins
> on mPCIe slots usable for such bluetooth mPCIe cards.
>
> For classic desktop / laptop it is needed to deal with fact that SCO
> audio is routed via HCI (like A2DP) and therefore support for Enhanced
> Setup Synchronous Connection HCI command.
>
> AFAIK even for routing SCO over PCM when mSBC hw encoder is used,
> Enhanced Setup Synchronous Connection HCI command is required.

So you are saying that we should do PCM over HCI and that would
actually work (meaning we have enough bandwidth)? From power point of
view this makes very little sense imo, since all the cycle we save on
no encoding we probably lose with more data to transmit, so are we
looking into use HW encoder just to fix the quality of codec?

-- 
Luiz Augusto von Dentz

Re: Default to HW mSBC on capable controllers ?

[Pali Rohár]

Hello!

On Monday 21 December 2020 17:54:56 Luiz Augusto von Dentz wrote:
> Hi Pali,
> 
> On Mon, Dec 21, 2020 at 1:14 PM Pali Rohár <pali@kernel.org> wrote:
> >
> > On Friday 18 December 2020 11:43:32 Luiz Augusto von Dentz wrote:
> > > Hi Joakim,
> > >
> > > On Fri, Dec 18, 2020 at 10:48 AM Joakim Tjernlund
> > > <Joakim.Tjernlund@infinera.com> wrote:
> > > >
> > > > There seems to be quite a few USB controllers gaining the BTUSB_WIDEBAND_SPEECH which I guess means HW mSBC but currently there is no way to select this mode.
> > > > Any idea if one could patch the kernel to default to HW mSBC and user apps like bluealsa/pulseaudio would just use it automatically?
> > >
> > > It is in our plan to support HW offloading, but that doesn't mean all
> > > platforms will be supported since that depends on the PCM lines being
> > > connected to BT controller in the first place.
> >
> > Dedicated PCM lines are used in embedded world and maybe also still in
> > some mobile segment. I remember that e.g. Nokia N900 had this setup. And
> > it was quite crazy how it was finally configured... but it worked!
> >
> > But this is nothing for classic x86 laptops with USB bluetooth
> > controllers on classic intel bluetooth+wifi mPCIe cards where SCO
> > traffic is routed via HCI (over USB). And not via dedicated PCM pins.
> > Moreover I think there are not any mainstream laptop which have PCM pins
> > on mPCIe slots usable for such bluetooth mPCIe cards.
> >
> > For classic desktop / laptop it is needed to deal with fact that SCO
> > audio is routed via HCI (like A2DP) and therefore support for Enhanced
> > Setup Synchronous Connection HCI command.
> >
> > AFAIK even for routing SCO over PCM when mSBC hw encoder is used,
> > Enhanced Setup Synchronous Connection HCI command is required.
> 
> So you are saying that we should do PCM over HCI and that would
> actually work (meaning we have enough bandwidth)?

This is something which needs to be tested. And without full
implementation (with control of all parameters) we cannot say YES or NO.

And if you are aware of bandwidth, Enhanced Setup Synchronous Connection
HCI command allows you to use also software based CVSD codec. Meaning
that CVSD encoding/decoding can be done by application and therefore
decreasing amount of data to transfer to bluetooth adapter.

As I said this command is needed also if you want to use mSBC hw encoder
over PCM, so I think usage of Enhanced Setup Synchronous Connection HCI
command always have benefits to implement it (I have unfinished and
untested implementation).

> From power point of
> view this makes very little sense imo, since all the cycle we save on
> no encoding we probably lose with more data to transmit, so are we
> looking into use HW encoder just to fix the quality of codec?

That is a good question if power consumption would be increased or
decreased. Anyway, hw encoding may be able to achieve lower latency. So
I rather do not drop it prematurely without any tests.

And another important thing, not all bluetooth adapters are USB based,
there are adapters connected over UART and SDIO. And every bus can
behave differently. USB is domain of laptops, UART can be found on
raspberry pi which is also heavily used. SDIO bluetooth is less used but
I have there at least device on which is running mainline kernel (5.10)
and has SDIO bluetooth.

RE: Default to HW mSBC on capable controllers ?

[Jamie Mccrae]

Hi,

> On Monday 21 December 2020 17:54:56 Luiz Augusto von Dentz wrote:
> > Hi Pali,
> >
> > On Mon, Dec 21, 2020 at 1:14 PM Pali Rohár <pali@kernel.org> wrote:
> > >
> > > On Friday 18 December 2020 11:43:32 Luiz Augusto von Dentz wrote:
> > > > Hi Joakim,
> > > >
> > > > On Fri, Dec 18, 2020 at 10:48 AM Joakim Tjernlund
> > > > <Joakim.Tjernlund@infinera.com> wrote:
> > > > >
> > > > > There seems to be quite a few USB controllers gaining the BTUSB_WIDEBAND_SPEECH which I guess means HW mSBC but currently there is no way to select this mode.
> > > > > Any idea if one could patch the kernel to default to HW mSBC and user apps like bluealsa/pulseaudio would just use it automatically?
> > > >
> > > > It is in our plan to support HW offloading, but that doesn't mean all
> > > > platforms will be supported since that depends on the PCM lines being
> > > > connected to BT controller in the first place.
> > >
> > > Dedicated PCM lines are used in embedded world and maybe also still in
> > > some mobile segment. I remember that e.g. Nokia N900 had this setup. And
> > > it was quite crazy how it was finally configured... but it worked!
> > >
> > > But this is nothing for classic x86 laptops with USB bluetooth
> > > controllers on classic intel bluetooth+wifi mPCIe cards where SCO
> > > traffic is routed via HCI (over USB). And not via dedicated PCM pins.
> > > Moreover I think there are not any mainstream laptop which have PCM pins
> > > on mPCIe slots usable for such bluetooth mPCIe cards.
> > >
> > > For classic desktop / laptop it is needed to deal with fact that SCO
> > > audio is routed via HCI (like A2DP) and therefore support for Enhanced
> > > Setup Synchronous Connection HCI command.
> > >
> > > AFAIK even for routing SCO over PCM when mSBC hw encoder is used,
> > > Enhanced Setup Synchronous Connection HCI command is required.
> >
> > So you are saying that we should do PCM over HCI and that would
> > actually work (meaning we have enough bandwidth)?
>
> This is something which needs to be tested. And without full
> implementation (with control of all parameters) we cannot say YES or NO.
>
> And if you are aware of bandwidth, Enhanced Setup Synchronous Connection
> HCI command allows you to use also software based CVSD codec. Meaning
> that CVSD encoding/decoding can be done by application and therefore
> decreasing amount of data to transfer to bluetooth adapter.
>
> As I said this command is needed also if you want to use mSBC hw encoder
> over PCM, so I think usage of Enhanced Setup Synchronous Connection HCI
> command always have benefits to implement it (I have unfinished and
> untested implementation).
>
> > From power point of
> > view this makes very little sense imo, since all the cycle we save on
> > no encoding we probably lose with more data to transmit, so are we
> > looking into use HW encoder just to fix the quality of codec?
>
> That is a good question if power consumption would be increased or
> decreased. Anyway, hw encoding may be able to achieve lower latency. So
> I rather do not drop it prematurely without any tests.
>
> And another important thing, not all bluetooth adapters are USB based,
> there are adapters connected over UART and SDIO. And every bus can
> behave differently. USB is domain of laptops, UART can be found on
> raspberry pi which is also heavily used. SDIO bluetooth is less used but
> I have there at least device on which is running mainline kernel (5.10)
> and has SDIO bluetooth.

Can confirm this, we have SDIO, USB and UART interfaces on the modules
we supply. There are some quirks on how to select routing for PCM, on
CSR based designs I'm not sure if this can be changed on the fly via
a command but the default can be changed via changing the PSKEY
configuration whilst in BCSP mode. On cypress modules you cannot
change it dynamically at all, it requires a different firmware (which,
conversely, cannot be obtained nor changed by users in the field).
Thanks,
Jamie
THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.

Re: Default to HW mSBC on capable controllers ?

[Pali Rohár]

On Tuesday 22 December 2020 09:36:48 Jamie Mccrae wrote:
> Hi,
> 
> > On Monday 21 December 2020 17:54:56 Luiz Augusto von Dentz wrote:
> > > Hi Pali,
> > >
> > > On Mon, Dec 21, 2020 at 1:14 PM Pali Rohár <pali@kernel.org> wrote:
> > > >
> > > > On Friday 18 December 2020 11:43:32 Luiz Augusto von Dentz wrote:
> > > > > Hi Joakim,
> > > > >
> > > > > On Fri, Dec 18, 2020 at 10:48 AM Joakim Tjernlund
> > > > > <Joakim.Tjernlund@infinera.com> wrote:
> > > > > >
> > > > > > There seems to be quite a few USB controllers gaining the BTUSB_WIDEBAND_SPEECH which I guess means HW mSBC but currently there is no way to select this mode.
> > > > > > Any idea if one could patch the kernel to default to HW mSBC and user apps like bluealsa/pulseaudio would just use it automatically?
> > > > >
> > > > > It is in our plan to support HW offloading, but that doesn't mean all
> > > > > platforms will be supported since that depends on the PCM lines being
> > > > > connected to BT controller in the first place.
> > > >
> > > > Dedicated PCM lines are used in embedded world and maybe also still in
> > > > some mobile segment. I remember that e.g. Nokia N900 had this setup. And
> > > > it was quite crazy how it was finally configured... but it worked!
> > > >
> > > > But this is nothing for classic x86 laptops with USB bluetooth
> > > > controllers on classic intel bluetooth+wifi mPCIe cards where SCO
> > > > traffic is routed via HCI (over USB). And not via dedicated PCM pins.
> > > > Moreover I think there are not any mainstream laptop which have PCM pins
> > > > on mPCIe slots usable for such bluetooth mPCIe cards.
> > > >
> > > > For classic desktop / laptop it is needed to deal with fact that SCO
> > > > audio is routed via HCI (like A2DP) and therefore support for Enhanced
> > > > Setup Synchronous Connection HCI command.
> > > >
> > > > AFAIK even for routing SCO over PCM when mSBC hw encoder is used,
> > > > Enhanced Setup Synchronous Connection HCI command is required.
> > >
> > > So you are saying that we should do PCM over HCI and that would
> > > actually work (meaning we have enough bandwidth)?
> >
> > This is something which needs to be tested. And without full
> > implementation (with control of all parameters) we cannot say YES or NO.
> >
> > And if you are aware of bandwidth, Enhanced Setup Synchronous Connection
> > HCI command allows you to use also software based CVSD codec. Meaning
> > that CVSD encoding/decoding can be done by application and therefore
> > decreasing amount of data to transfer to bluetooth adapter.
> >
> > As I said this command is needed also if you want to use mSBC hw encoder
> > over PCM, so I think usage of Enhanced Setup Synchronous Connection HCI
> > command always have benefits to implement it (I have unfinished and
> > untested implementation).
> >
> > > From power point of
> > > view this makes very little sense imo, since all the cycle we save on
> > > no encoding we probably lose with more data to transmit, so are we
> > > looking into use HW encoder just to fix the quality of codec?
> >
> > That is a good question if power consumption would be increased or
> > decreased. Anyway, hw encoding may be able to achieve lower latency. So
> > I rather do not drop it prematurely without any tests.
> >
> > And another important thing, not all bluetooth adapters are USB based,
> > there are adapters connected over UART and SDIO. And every bus can
> > behave differently. USB is domain of laptops, UART can be found on
> > raspberry pi which is also heavily used. SDIO bluetooth is less used but
> > I have there at least device on which is running mainline kernel (5.10)
> > and has SDIO bluetooth.
> 
> Can confirm this, we have SDIO, USB and UART interfaces on the modules
> we supply.

I know :-) I have one of those your devel kits with jumpers for
selecting SDIO/USB/UART interface.

> There are some quirks on how to select routing for PCM, on

The nice feature of Enhanced Setup Synchronous Connection HCI command is
that you can choose routing (HCI or PCI) as argument of this command.

> CSR based designs I'm not sure if this can be changed on the fly via
> a command

If your adapter supports standard Enhanced Setup Synchronous Connection
HCI command and implement it according to specification, then yes, it
should support changing it via command without need to set any quirk or
jumper on board.

You may verify what your adapters support by script sco_features:
https://github.com/pali/hsphfpd-prototype/blob/prototype/sco_features.pl

> but the default can be changed via changing the PSKEY
> configuration whilst in BCSP mode. On cypress modules you cannot
> change it dynamically at all, it requires a different firmware (which,
> conversely, cannot be obtained nor changed by users in the field).
> Thanks,
> Jamie
> THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.

Re: Default to HW mSBC on capable controllers ?

[Marcel Holtmann]

Hi Pali,

>>>>> There seems to be quite a few USB controllers gaining the BTUSB_WIDEBAND_SPEECH which I guess means HW mSBC but currently there is no way to select this mode.
>>>>> Any idea if one could patch the kernel to default to HW mSBC and user apps like bluealsa/pulseaudio would just use it automatically?
>>>> 
>>>> It is in our plan to support HW offloading, but that doesn't mean all
>>>> platforms will be supported since that depends on the PCM lines being
>>>> connected to BT controller in the first place.
>>> 
>>> Dedicated PCM lines are used in embedded world and maybe also still in
>>> some mobile segment. I remember that e.g. Nokia N900 had this setup. And
>>> it was quite crazy how it was finally configured... but it worked!
>>> 
>>> But this is nothing for classic x86 laptops with USB bluetooth
>>> controllers on classic intel bluetooth+wifi mPCIe cards where SCO
>>> traffic is routed via HCI (over USB). And not via dedicated PCM pins.
>>> Moreover I think there are not any mainstream laptop which have PCM pins
>>> on mPCIe slots usable for such bluetooth mPCIe cards.
>>> 
>>> For classic desktop / laptop it is needed to deal with fact that SCO
>>> audio is routed via HCI (like A2DP) and therefore support for Enhanced
>>> Setup Synchronous Connection HCI command.
>>> 
>>> AFAIK even for routing SCO over PCM when mSBC hw encoder is used,
>>> Enhanced Setup Synchronous Connection HCI command is required.
>> 
>> So you are saying that we should do PCM over HCI and that would
>> actually work (meaning we have enough bandwidth)?
> 
> This is something which needs to be tested. And without full
> implementation (with control of all parameters) we cannot say YES or NO.
> 
> And if you are aware of bandwidth, Enhanced Setup Synchronous Connection
> HCI command allows you to use also software based CVSD codec. Meaning
> that CVSD encoding/decoding can be done by application and therefore
> decreasing amount of data to transfer to bluetooth adapter.
> 
> As I said this command is needed also if you want to use mSBC hw encoder
> over PCM, so I think usage of Enhanced Setup Synchronous Connection HCI
> command always have benefits to implement it (I have unfinished and
> untested implementation).

CVSD is an air codec only. Controller<->Host is PCM in that case. Only with mSBC you have both air codec and Controller<->Host running with mSBC.

Regards

Marcel

Re: Default to HW mSBC on capable controllers ?

[Pali Rohár]

On Tuesday 22 December 2020 11:05:19 Marcel Holtmann wrote:
> Hi Pali,
> 
> >>>>> There seems to be quite a few USB controllers gaining the BTUSB_WIDEBAND_SPEECH which I guess means HW mSBC but currently there is no way to select this mode.
> >>>>> Any idea if one could patch the kernel to default to HW mSBC and user apps like bluealsa/pulseaudio would just use it automatically?
> >>>> 
> >>>> It is in our plan to support HW offloading, but that doesn't mean all
> >>>> platforms will be supported since that depends on the PCM lines being
> >>>> connected to BT controller in the first place.
> >>> 
> >>> Dedicated PCM lines are used in embedded world and maybe also still in
> >>> some mobile segment. I remember that e.g. Nokia N900 had this setup. And
> >>> it was quite crazy how it was finally configured... but it worked!
> >>> 
> >>> But this is nothing for classic x86 laptops with USB bluetooth
> >>> controllers on classic intel bluetooth+wifi mPCIe cards where SCO
> >>> traffic is routed via HCI (over USB). And not via dedicated PCM pins.
> >>> Moreover I think there are not any mainstream laptop which have PCM pins
> >>> on mPCIe slots usable for such bluetooth mPCIe cards.
> >>> 
> >>> For classic desktop / laptop it is needed to deal with fact that SCO
> >>> audio is routed via HCI (like A2DP) and therefore support for Enhanced
> >>> Setup Synchronous Connection HCI command.
> >>> 
> >>> AFAIK even for routing SCO over PCM when mSBC hw encoder is used,
> >>> Enhanced Setup Synchronous Connection HCI command is required.
> >> 
> >> So you are saying that we should do PCM over HCI and that would
> >> actually work (meaning we have enough bandwidth)?
> > 
> > This is something which needs to be tested. And without full
> > implementation (with control of all parameters) we cannot say YES or NO.
> > 
> > And if you are aware of bandwidth, Enhanced Setup Synchronous Connection
> > HCI command allows you to use also software based CVSD codec. Meaning
> > that CVSD encoding/decoding can be done by application and therefore
> > decreasing amount of data to transfer to bluetooth adapter.
> > 
> > As I said this command is needed also if you want to use mSBC hw encoder
> > over PCM, so I think usage of Enhanced Setup Synchronous Connection HCI
> > command always have benefits to implement it (I have unfinished and
> > untested implementation).
> 
> CVSD is an air codec only. Controller<->Host is PCM in that case.

Hello!

This is not fully truth. You can use also use CVSD between Controller
and Host. Enhanced Setup Synchronous Connection HCI allows you to do it.

> Only with mSBC you have both air codec and Controller<->Host running with mSBC.

No, you can use it also with other codecs. With all transparent codecs
and CVSD, alaw and ulaw based on capabilities of your bluetooth
adapters.

> Regards
> 
> Marcel
> 
> 

Re: Default to HW mSBC on capable controllers ?

[Marcel Holtmann]

Hi Pali,

>>>>>>> There seems to be quite a few USB controllers gaining the BTUSB_WIDEBAND_SPEECH which I guess means HW mSBC but currently there is no way to select this mode.
>>>>>>> Any idea if one could patch the kernel to default to HW mSBC and user apps like bluealsa/pulseaudio would just use it automatically?
>>>>>> 
>>>>>> It is in our plan to support HW offloading, but that doesn't mean all
>>>>>> platforms will be supported since that depends on the PCM lines being
>>>>>> connected to BT controller in the first place.
>>>>> 
>>>>> Dedicated PCM lines are used in embedded world and maybe also still in
>>>>> some mobile segment. I remember that e.g. Nokia N900 had this setup. And
>>>>> it was quite crazy how it was finally configured... but it worked!
>>>>> 
>>>>> But this is nothing for classic x86 laptops with USB bluetooth
>>>>> controllers on classic intel bluetooth+wifi mPCIe cards where SCO
>>>>> traffic is routed via HCI (over USB). And not via dedicated PCM pins.
>>>>> Moreover I think there are not any mainstream laptop which have PCM pins
>>>>> on mPCIe slots usable for such bluetooth mPCIe cards.
>>>>> 
>>>>> For classic desktop / laptop it is needed to deal with fact that SCO
>>>>> audio is routed via HCI (like A2DP) and therefore support for Enhanced
>>>>> Setup Synchronous Connection HCI command.
>>>>> 
>>>>> AFAIK even for routing SCO over PCM when mSBC hw encoder is used,
>>>>> Enhanced Setup Synchronous Connection HCI command is required.
>>>> 
>>>> So you are saying that we should do PCM over HCI and that would
>>>> actually work (meaning we have enough bandwidth)?
>>> 
>>> This is something which needs to be tested. And without full
>>> implementation (with control of all parameters) we cannot say YES or NO.
>>> 
>>> And if you are aware of bandwidth, Enhanced Setup Synchronous Connection
>>> HCI command allows you to use also software based CVSD codec. Meaning
>>> that CVSD encoding/decoding can be done by application and therefore
>>> decreasing amount of data to transfer to bluetooth adapter.
>>> 
>>> As I said this command is needed also if you want to use mSBC hw encoder
>>> over PCM, so I think usage of Enhanced Setup Synchronous Connection HCI
>>> command always have benefits to implement it (I have unfinished and
>>> untested implementation).
>> 
>> CVSD is an air codec only. Controller<->Host is PCM in that case.
> 
> Hello!
> 
> This is not fully truth. You can use also use CVSD between Controller
> and Host. Enhanced Setup Synchronous Connection HCI allows you to do it.

so the spec is unclear in case of HCI transport. It could be stipulated that CVSD is also possible. However it is not practical since the controller would have to re-encode in case a different air codec is used. The reality is that all “legacy” devices decided for CVSD air codec and PCM host codec.

Going into this direction of allowing CVSD as host codec is just a waste of time.

>> Only with mSBC you have both air codec and Controller<->Host running with mSBC.
> 
> No, you can use it also with other codecs. With all transparent codecs
> and CVSD, alaw and ulaw based on capabilities of your bluetooth
> adapters.

The case when it is not CVSD, alaw and ulaw is pretty clear written in the spec. Both have to be transparent. I think that the spec and the assigned numbers document is not really clear in specifying which of the Coding_Format fields apply when HCI transport is used vs external channel.

I would really assume that when the host is running the codec, then it is transparent. When the codec is offload to the controller, then the host transport is Linear PCM.

So you I would plan for CVSD<->CVSD<->PCM, Transparent<->{mSBC,LC3}<->PCM, Transparent<->Transparent<->{mSBC,LC3} for the SCO/eSCO cases.

Regards

Marcel

Re: Default to HW mSBC on capable controllers ?

[Pasi Kärkkäinen]

Hello Pali,

On Mon, Dec 21, 2020 at 10:07:07PM +0100, Pali Rohár wrote:
> 
> > Any idea if one could patch the kernel to default to HW mSBC and user apps like bluealsa/pulseaudio would just use it automatically?
> 
> For usage mSBC hw encoder you need to use Enhanced Setup Synchronous
> Connection HCI command for establishing SCO connection.
> 
> For using HW encoder you need to stop feeding socket with mSBC encoded
> data and instead put into this socket RAW pcm samples. Also you need
> somehow inform kernel about this change.
> 
> For both things I designed new setsockopt() API which I described in:
> https://lore.kernel.org/linux-bluetooth/20200419234937.4zozkqgpt557m3o6@pali/
>

In that thread Luiz asked for changes to the patch, eg. kernel module option is needed which allows enabling new/experimental features, and your changes should be enabled only when experimental option is given while loading the module.

See here:
https://lore.kernel.org/linux-bluetooth/CABBYNZJTBM87Yr+rqUm6MwwSR60YNe+UFr0HHj5T2DkY7LqJqA@mail.gmail.com/

Could you please add that kernel module option, and re-send the patch ? 


Thanks,

-- Pasi

Re: Default to HW mSBC on capable controllers ?

[Pali Rohár]

Hello!

On Tuesday 22 December 2020 12:04:52 Marcel Holtmann wrote:
> Hi Pali,
> 
> >>>>>>> There seems to be quite a few USB controllers gaining the BTUSB_WIDEBAND_SPEECH which I guess means HW mSBC but currently there is no way to select this mode.
> >>>>>>> Any idea if one could patch the kernel to default to HW mSBC and user apps like bluealsa/pulseaudio would just use it automatically?
> >>>>>> 
> >>>>>> It is in our plan to support HW offloading, but that doesn't mean all
> >>>>>> platforms will be supported since that depends on the PCM lines being
> >>>>>> connected to BT controller in the first place.
> >>>>> 
> >>>>> Dedicated PCM lines are used in embedded world and maybe also still in
> >>>>> some mobile segment. I remember that e.g. Nokia N900 had this setup. And
> >>>>> it was quite crazy how it was finally configured... but it worked!
> >>>>> 
> >>>>> But this is nothing for classic x86 laptops with USB bluetooth
> >>>>> controllers on classic intel bluetooth+wifi mPCIe cards where SCO
> >>>>> traffic is routed via HCI (over USB). And not via dedicated PCM pins.
> >>>>> Moreover I think there are not any mainstream laptop which have PCM pins
> >>>>> on mPCIe slots usable for such bluetooth mPCIe cards.
> >>>>> 
> >>>>> For classic desktop / laptop it is needed to deal with fact that SCO
> >>>>> audio is routed via HCI (like A2DP) and therefore support for Enhanced
> >>>>> Setup Synchronous Connection HCI command.
> >>>>> 
> >>>>> AFAIK even for routing SCO over PCM when mSBC hw encoder is used,
> >>>>> Enhanced Setup Synchronous Connection HCI command is required.
> >>>> 
> >>>> So you are saying that we should do PCM over HCI and that would
> >>>> actually work (meaning we have enough bandwidth)?
> >>> 
> >>> This is something which needs to be tested. And without full
> >>> implementation (with control of all parameters) we cannot say YES or NO.
> >>> 
> >>> And if you are aware of bandwidth, Enhanced Setup Synchronous Connection
> >>> HCI command allows you to use also software based CVSD codec. Meaning
> >>> that CVSD encoding/decoding can be done by application and therefore
> >>> decreasing amount of data to transfer to bluetooth adapter.
> >>> 
> >>> As I said this command is needed also if you want to use mSBC hw encoder
> >>> over PCM, so I think usage of Enhanced Setup Synchronous Connection HCI
> >>> command always have benefits to implement it (I have unfinished and
> >>> untested implementation).
> >> 
> >> CVSD is an air codec only. Controller<->Host is PCM in that case.
> > 
> > Hello!
> > 
> > This is not fully truth. You can use also use CVSD between Controller
> > and Host. Enhanced Setup Synchronous Connection HCI allows you to do it.
> 
> so the spec is unclear in case of HCI transport. It could be stipulated that CVSD is also possible. However it is not practical since the controller would have to re-encode in case a different air codec is used. The reality is that all “legacy” devices decided for CVSD air codec and PCM host codec.
> 
> Going into this direction of allowing CVSD as host codec is just a waste of time.

Well, people are complaining about CVSD quality and there are still lot
of headsets which support only CVSD. Therefore I see a good reason to
try encode/decode of CVSD in software and check if software encoder or
decoder cannot increase this quality. I'm not saying that it can really
improve it but without testing we do not know. And as I know how poor
are some hardware implementations of codecs (but not all) I would not be
surprised if for some bluetooth adapters this can really increase
quality for CVSD transports... But without real tests we do not know.

> >> Only with mSBC you have both air codec and Controller<->Host running with mSBC.
> > 
> > No, you can use it also with other codecs. With all transparent codecs
> > and CVSD, alaw and ulaw based on capabilities of your bluetooth
> > adapters.
> 
> The case when it is not CVSD, alaw and ulaw is pretty clear written in the spec. Both have to be transparent.

Yes, for air part it has to be either: CVSD, ALAW, ULAW or TRANSPARENT.
So all other additional codecs use transparent on AIR part.

But on local part it can be also any other codec defined in some
assigned number document.

> I think that the spec and the assigned numbers document is not really clear in specifying which of the Coding_Format fields apply when HCI transport is used vs external channel.

It is months ago when I read specification last time, but I think that
at the time when I read it I understood that also CVSD codec may be used
by local part if is supported.

> I would really assume that when the host is running the codec, then it is transparent.

This is truth for "Setup Synchronous Connection". But not for "Enhanced
Setup Synchronous Connection". In "Enhanced" version you can have local
codec for host also "CVSD", also "mSBC" and also any other which adapter
returns in the "local codec" list or in "vendor codec" list. And for
local part in "Enhanced" version this is *not* transparent anymore.

Of course "Enhanced" version support also "transparent" code and behave
like in classic non-enhanced version.

> When the codec is offload to the controller, then the host transport is Linear PCM.
> 
> So you I would plan for CVSD<->CVSD<->PCM, Transparent<->{mSBC,LC3}<->PCM, Transparent<->Transparent<->{mSBC,LC3} for the SCO/eSCO cases.

You forgot AuriStream codec which is used and heavily supported by lot
of headsets. Just people do not know that is is supported.

I would really suggest to look at my API for specifying codec parameters
on socket and allow usage of "Enhanced Setup Synchronous Connection".

I do not think it is waste of time. At least it allows doing all kind of
test what adapters support and what is the quality of transport.

> Regards
> 
> Marcel
> 

Re: Default to HW mSBC on capable controllers ?

[Pali Rohár]

On Tuesday 22 December 2020 13:40:24 Pasi Kärkkäinen wrote:
> Hello Pali,
> 
> On Mon, Dec 21, 2020 at 10:07:07PM +0100, Pali Rohár wrote:
> > 
> > > Any idea if one could patch the kernel to default to HW mSBC and user apps like bluealsa/pulseaudio would just use it automatically?
> > 
> > For usage mSBC hw encoder you need to use Enhanced Setup Synchronous
> > Connection HCI command for establishing SCO connection.
> > 
> > For using HW encoder you need to stop feeding socket with mSBC encoded
> > data and instead put into this socket RAW pcm samples. Also you need
> > somehow inform kernel about this change.
> > 
> > For both things I designed new setsockopt() API which I described in:
> > https://lore.kernel.org/linux-bluetooth/20200419234937.4zozkqgpt557m3o6@pali/
> >
> 
> In that thread Luiz asked for changes to the patch, eg. kernel module option is needed which allows enabling new/experimental features, and your changes should be enabled only when experimental option is given while loading the module.
> 
> See here:
> https://lore.kernel.org/linux-bluetooth/CABBYNZJTBM87Yr+rqUm6MwwSR60YNe+UFr0HHj5T2DkY7LqJqA@mail.gmail.com/
> 
> Could you please add that kernel module option, and re-send the patch ? 

I have not implemented it. I just proposed API between userspace and
kernel. But I have not implemented this API yet.

Re: Default to HW mSBC on capable controllers ?

[Marcel Holtmann]

Hi Pali,

>>>>>>>>> There seems to be quite a few USB controllers gaining the BTUSB_WIDEBAND_SPEECH which I guess means HW mSBC but currently there is no way to select this mode.
>>>>>>>>> Any idea if one could patch the kernel to default to HW mSBC and user apps like bluealsa/pulseaudio would just use it automatically?
>>>>>>>> 
>>>>>>>> It is in our plan to support HW offloading, but that doesn't mean all
>>>>>>>> platforms will be supported since that depends on the PCM lines being
>>>>>>>> connected to BT controller in the first place.
>>>>>>> 
>>>>>>> Dedicated PCM lines are used in embedded world and maybe also still in
>>>>>>> some mobile segment. I remember that e.g. Nokia N900 had this setup. And
>>>>>>> it was quite crazy how it was finally configured... but it worked!
>>>>>>> 
>>>>>>> But this is nothing for classic x86 laptops with USB bluetooth
>>>>>>> controllers on classic intel bluetooth+wifi mPCIe cards where SCO
>>>>>>> traffic is routed via HCI (over USB). And not via dedicated PCM pins.
>>>>>>> Moreover I think there are not any mainstream laptop which have PCM pins
>>>>>>> on mPCIe slots usable for such bluetooth mPCIe cards.
>>>>>>> 
>>>>>>> For classic desktop / laptop it is needed to deal with fact that SCO
>>>>>>> audio is routed via HCI (like A2DP) and therefore support for Enhanced
>>>>>>> Setup Synchronous Connection HCI command.
>>>>>>> 
>>>>>>> AFAIK even for routing SCO over PCM when mSBC hw encoder is used,
>>>>>>> Enhanced Setup Synchronous Connection HCI command is required.
>>>>>> 
>>>>>> So you are saying that we should do PCM over HCI and that would
>>>>>> actually work (meaning we have enough bandwidth)?
>>>>> 
>>>>> This is something which needs to be tested. And without full
>>>>> implementation (with control of all parameters) we cannot say YES or NO.
>>>>> 
>>>>> And if you are aware of bandwidth, Enhanced Setup Synchronous Connection
>>>>> HCI command allows you to use also software based CVSD codec. Meaning
>>>>> that CVSD encoding/decoding can be done by application and therefore
>>>>> decreasing amount of data to transfer to bluetooth adapter.
>>>>> 
>>>>> As I said this command is needed also if you want to use mSBC hw encoder
>>>>> over PCM, so I think usage of Enhanced Setup Synchronous Connection HCI
>>>>> command always have benefits to implement it (I have unfinished and
>>>>> untested implementation).
>>>> 
>>>> CVSD is an air codec only. Controller<->Host is PCM in that case.
>>> 
>>> Hello!
>>> 
>>> This is not fully truth. You can use also use CVSD between Controller
>>> and Host. Enhanced Setup Synchronous Connection HCI allows you to do it.
>> 
>> so the spec is unclear in case of HCI transport. It could be stipulated that CVSD is also possible. However it is not practical since the controller would have to re-encode in case a different air codec is used. The reality is that all “legacy” devices decided for CVSD air codec and PCM host codec.
>> 
>> Going into this direction of allowing CVSD as host codec is just a waste of time.
> 
> Well, people are complaining about CVSD quality and there are still lot
> of headsets which support only CVSD. Therefore I see a good reason to
> try encode/decode of CVSD in software and check if software encoder or
> decoder cannot increase this quality. I'm not saying that it can really
> improve it but without testing we do not know. And as I know how poor
> are some hardware implementations of codecs (but not all) I would not be
> surprised if for some bluetooth adapters this can really increase
> quality for CVSD transports... But without real tests we do not know.

I really don’t see how this is going to help. I have no interest in this. I think it is a waste of time.

>>>> Only with mSBC you have both air codec and Controller<->Host running with mSBC.
>>> 
>>> No, you can use it also with other codecs. With all transparent codecs
>>> and CVSD, alaw and ulaw based on capabilities of your bluetooth
>>> adapters.
>> 
>> The case when it is not CVSD, alaw and ulaw is pretty clear written in the spec. Both have to be transparent.
> 
> Yes, for air part it has to be either: CVSD, ALAW, ULAW or TRANSPARENT.
> So all other additional codecs use transparent on AIR part.
> 
> But on local part it can be also any other codec defined in some
> assigned number document.

That is not clearly defined. The Codec_Format is an enumeration that is used in multiple places. I think that table is missing an indication what values are valid for certain HCI commands and protocols. We did this for other assigned numbers as well.

As I said, I see zero benefit of using CVSD as input/output codec over HCI.

>> I think that the spec and the assigned numbers document is not really clear in specifying which of the Coding_Format fields apply when HCI transport is used vs external channel.
> 
> It is months ago when I read specification last time, but I think that
> at the time when I read it I understood that also CVSD codec may be used
> by local part if is supported.
> 
>> I would really assume that when the host is running the codec, then it is transparent.
> 
> This is truth for "Setup Synchronous Connection". But not for "Enhanced
> Setup Synchronous Connection". In "Enhanced" version you can have local
> codec for host also "CVSD", also "mSBC" and also any other which adapter
> returns in the "local codec" list or in "vendor codec" list. And for
> local part in "Enhanced" version this is *not* transparent anymore.
> 
> Of course "Enhanced" version support also "transparent" code and behave
> like in classic non-enhanced version.

Read my comment again since I did check the spec. It is super unclear on what values are support for input/output codec format when using HCI transport. I bet you that once you try this, you will see limitation in the controllers and they are just telling you Invalid Parameters.

>> When the codec is offload to the controller, then the host transport is Linear PCM.
>> 
>> So you I would plan for CVSD<->CVSD<->PCM, Transparent<->{mSBC,LC3}<->PCM, Transparent<->Transparent<->{mSBC,LC3} for the SCO/eSCO cases.
> 
> You forgot AuriStream codec which is used and heavily supported by lot
> of headsets. Just people do not know that is is supported.

But then again, that is Transparent. So Transparent<->Transparent<->{mSBC,LC3,AuriStream,etc}.

> I would really suggest to look at my API for specifying codec parameters
> on socket and allow usage of "Enhanced Setup Synchronous Connection".
> 
> I do not think it is waste of time. At least it allows doing all kind of
> test what adapters support and what is the quality of transport.

I am not going to expose the full crazy that is that HCI command to userspace. We can support the sensible ones. If you want to toy with CVSD, alaw and ulaw, then by all means, but not in an official API.

We really need to get serious, the Bluetooth standard for SCO is over 20+ years old and eSCO has been around for almost as long. Even HFP Wideband speech has been around for many many years. There is no need for alaw and ulaw in Bluetooth. Period. And CVSD is used as legacy air codec and that is it.

Regards

Marcel

Re: Default to HW mSBC on capable controllers ?

[Pali Rohár]

Hello!

On Tuesday 22 December 2020 13:20:27 Marcel Holtmann wrote:
> Hi Pali,
> 
> >>>>>>>>> There seems to be quite a few USB controllers gaining the BTUSB_WIDEBAND_SPEECH which I guess means HW mSBC but currently there is no way to select this mode.
> >>>>>>>>> Any idea if one could patch the kernel to default to HW mSBC and user apps like bluealsa/pulseaudio would just use it automatically?
> >>>>>>>> 
> >>>>>>>> It is in our plan to support HW offloading, but that doesn't mean all
> >>>>>>>> platforms will be supported since that depends on the PCM lines being
> >>>>>>>> connected to BT controller in the first place.
> >>>>>>> 
> >>>>>>> Dedicated PCM lines are used in embedded world and maybe also still in
> >>>>>>> some mobile segment. I remember that e.g. Nokia N900 had this setup. And
> >>>>>>> it was quite crazy how it was finally configured... but it worked!
> >>>>>>> 
> >>>>>>> But this is nothing for classic x86 laptops with USB bluetooth
> >>>>>>> controllers on classic intel bluetooth+wifi mPCIe cards where SCO
> >>>>>>> traffic is routed via HCI (over USB). And not via dedicated PCM pins.
> >>>>>>> Moreover I think there are not any mainstream laptop which have PCM pins
> >>>>>>> on mPCIe slots usable for such bluetooth mPCIe cards.
> >>>>>>> 
> >>>>>>> For classic desktop / laptop it is needed to deal with fact that SCO
> >>>>>>> audio is routed via HCI (like A2DP) and therefore support for Enhanced
> >>>>>>> Setup Synchronous Connection HCI command.
> >>>>>>> 
> >>>>>>> AFAIK even for routing SCO over PCM when mSBC hw encoder is used,
> >>>>>>> Enhanced Setup Synchronous Connection HCI command is required.
> >>>>>> 
> >>>>>> So you are saying that we should do PCM over HCI and that would
> >>>>>> actually work (meaning we have enough bandwidth)?
> >>>>> 
> >>>>> This is something which needs to be tested. And without full
> >>>>> implementation (with control of all parameters) we cannot say YES or NO.
> >>>>> 
> >>>>> And if you are aware of bandwidth, Enhanced Setup Synchronous Connection
> >>>>> HCI command allows you to use also software based CVSD codec. Meaning
> >>>>> that CVSD encoding/decoding can be done by application and therefore
> >>>>> decreasing amount of data to transfer to bluetooth adapter.
> >>>>> 
> >>>>> As I said this command is needed also if you want to use mSBC hw encoder
> >>>>> over PCM, so I think usage of Enhanced Setup Synchronous Connection HCI
> >>>>> command always have benefits to implement it (I have unfinished and
> >>>>> untested implementation).
> >>>> 
> >>>> CVSD is an air codec only. Controller<->Host is PCM in that case.
> >>> 
> >>> Hello!
> >>> 
> >>> This is not fully truth. You can use also use CVSD between Controller
> >>> and Host. Enhanced Setup Synchronous Connection HCI allows you to do it.
> >> 
> >> so the spec is unclear in case of HCI transport. It could be stipulated that CVSD is also possible. However it is not practical since the controller would have to re-encode in case a different air codec is used. The reality is that all “legacy” devices decided for CVSD air codec and PCM host codec.
> >> 
> >> Going into this direction of allowing CVSD as host codec is just a waste of time.
> > 
> > Well, people are complaining about CVSD quality and there are still lot
> > of headsets which support only CVSD. Therefore I see a good reason to
> > try encode/decode of CVSD in software and check if software encoder or
> > decoder cannot increase this quality. I'm not saying that it can really
> > improve it but without testing we do not know. And as I know how poor
> > are some hardware implementations of codecs (but not all) I would not be
> > surprised if for some bluetooth adapters this can really increase
> > quality for CVSD transports... But without real tests we do not know.
> 
> I really don’t see how this is going to help. I have no interest in this. I think it is a waste of time.

It is simple. If hw encoder is poor you can write your own in software.
Then you can compare audio quality of hw encoder in adapter and software
encoder in userspace.

I'm sure that people are interested even in increasing quality of CVSD
transport and they can spend time on own userspace codec.

I understand that it does not bring any value for you and it can be a
waste of time for you.

But please do not block research in this field which can be done by
other people independently of you.

The worst what can happen is that (independent) researcher just confirms
what you have wrote. But even this would be very positive conclusion!

> >>>> Only with mSBC you have both air codec and Controller<->Host running with mSBC.
> >>> 
> >>> No, you can use it also with other codecs. With all transparent codecs
> >>> and CVSD, alaw and ulaw based on capabilities of your bluetooth
> >>> adapters.
> >> 
> >> The case when it is not CVSD, alaw and ulaw is pretty clear written in the spec. Both have to be transparent.
> > 
> > Yes, for air part it has to be either: CVSD, ALAW, ULAW or TRANSPARENT.
> > So all other additional codecs use transparent on AIR part.
> > 
> > But on local part it can be also any other codec defined in some
> > assigned number document.
> 
> That is not clearly defined. The Codec_Format is an enumeration that is used in multiple places. I think that table is missing an indication what values are valid for certain HCI commands and protocols. We did this for other assigned numbers as well.
> 
> As I said, I see zero benefit of using CVSD as input/output codec over HCI.

Yes, it is unclear and therefore research in this field by other people
can be interesting. To know what is reality.

I'm not saying that you have to use it. My argument is to allow other
people to do it and do not block them.

> >> I think that the spec and the assigned numbers document is not really clear in specifying which of the Coding_Format fields apply when HCI transport is used vs external channel.
> > 
> > It is months ago when I read specification last time, but I think that
> > at the time when I read it I understood that also CVSD codec may be used
> > by local part if is supported.
> > 
> >> I would really assume that when the host is running the codec, then it is transparent.
> > 
> > This is truth for "Setup Synchronous Connection". But not for "Enhanced
> > Setup Synchronous Connection". In "Enhanced" version you can have local
> > codec for host also "CVSD", also "mSBC" and also any other which adapter
> > returns in the "local codec" list or in "vendor codec" list. And for
> > local part in "Enhanced" version this is *not* transparent anymore.
> > 
> > Of course "Enhanced" version support also "transparent" code and behave
> > like in classic non-enhanced version.
> 
> Read my comment again since I did check the spec. It is super unclear on what values are support for input/output codec format when using HCI transport. I bet you that once you try this, you will see limitation in the controllers and they are just telling you Invalid Parameters.
> 
> >> When the codec is offload to the controller, then the host transport is Linear PCM.
> >> 
> >> So you I would plan for CVSD<->CVSD<->PCM, Transparent<->{mSBC,LC3}<->PCM, Transparent<->Transparent<->{mSBC,LC3} for the SCO/eSCO cases.
> > 
> > You forgot AuriStream codec which is used and heavily supported by lot
> > of headsets. Just people do not know that is is supported.
> 
> But then again, that is Transparent. So Transparent<->Transparent<->{mSBC,LC3,AuriStream,etc}.

Yes, it is transparent, but with different parameters which needs to be
passed to Setup Synchronous Connection parameters. And because this
codec is SW, encoding and decoding is done in software, userspace must
be able to "tune" parameters for Setup Synchronous Connection command.

Without it, it is not possible to use AuriStream codec, even it is
Transparent.

> > I would really suggest to look at my API for specifying codec parameters
> > on socket and allow usage of "Enhanced Setup Synchronous Connection".
> > 
> > I do not think it is waste of time. At least it allows doing all kind of
> > test what adapters support and what is the quality of transport.
> 
> I am not going to expose the full crazy that is that HCI command to userspace.

Ok, I understand that you do not like alaw and ulaw codecs. But do not
block usage of AuriStream. This codec is supported by many headsets and
has better quality than CVSD (which is currently supported by kernel).

Also, please keep in mind that alaw and ulaw codecs are
telecommunication standards and these codecs are still used.

People leaving in Europe and working in telecommunication sector would
know that alaw is codec main voice codec for audio PSTN calls and is
used also in VOIP lines.

So even if you marked it as legacy, it does not mean that it is not
used. Yes, it is legacy, but it is still there and tons of voice calls
in Europe are encoded in alaw.

But at least, please do not blok usage of AuriStream codec by Linux
kernel. People are complaining about bad quality, AuriStream can improve
it, but this decision just say "we do not want improvement".

I was open for any discussion how to bring it, but for one year I have
received any positive reaction how to achieve it. I designed API which
would allow it but there was no discussion about it, how to either
improve it or something else.

> We can support the sensible ones. If you want to toy with CVSD, alaw and ulaw, then by all means, but not in an official API.
> 
> We really need to get serious, the Bluetooth standard for SCO is over 20+ years old and eSCO has been around for almost as long. Even HFP Wideband speech has been around for many many years. There is no need for alaw and ulaw in Bluetooth. Period. And CVSD is used as legacy air codec and that is it.
> 
> Regards
> 
> Marcel
> 

Re: Default to HW mSBC on capable controllers ?

[Pali Rohár]

On Tuesday 22 December 2020 12:49:40 Pali Rohár wrote:
> On Tuesday 22 December 2020 13:40:24 Pasi Kärkkäinen wrote:
> > Hello Pali,
> > 
> > On Mon, Dec 21, 2020 at 10:07:07PM +0100, Pali Rohár wrote:
> > > 
> > > > Any idea if one could patch the kernel to default to HW mSBC and user apps like bluealsa/pulseaudio would just use it automatically?
> > > 
> > > For usage mSBC hw encoder you need to use Enhanced Setup Synchronous
> > > Connection HCI command for establishing SCO connection.
> > > 
> > > For using HW encoder you need to stop feeding socket with mSBC encoded
> > > data and instead put into this socket RAW pcm samples. Also you need
> > > somehow inform kernel about this change.
> > > 
> > > For both things I designed new setsockopt() API which I described in:
> > > https://lore.kernel.org/linux-bluetooth/20200419234937.4zozkqgpt557m3o6@pali/
> > >
> > 
> > In that thread Luiz asked for changes to the patch, eg. kernel module option is needed which allows enabling new/experimental features, and your changes should be enabled only when experimental option is given while loading the module.
> > 
> > See here:
> > https://lore.kernel.org/linux-bluetooth/CABBYNZJTBM87Yr+rqUm6MwwSR60YNe+UFr0HHj5T2DkY7LqJqA@mail.gmail.com/
> > 
> > Could you please add that kernel module option, and re-send the patch ? 

Pasi, I understood that Marcel is against it. But if bluetooth
maintainers approve this API, I may try to implement it. If API must be
hidden under compile time CONFIG_* kernel option it is also possible.
Just I need to know exact answer "yes" or "no".

> I have not implemented it. I just proposed API between userspace and
> kernel. But I have not implemented this API yet.

Re: Default to HW mSBC on capable controllers ?

[Marcel Holtmann]

Hi Pali,

>>>>>>>>>>> There seems to be quite a few USB controllers gaining the BTUSB_WIDEBAND_SPEECH which I guess means HW mSBC but currently there is no way to select this mode.
>>>>>>>>>>> Any idea if one could patch the kernel to default to HW mSBC and user apps like bluealsa/pulseaudio would just use it automatically?
>>>>>>>>>> 
>>>>>>>>>> It is in our plan to support HW offloading, but that doesn't mean all
>>>>>>>>>> platforms will be supported since that depends on the PCM lines being
>>>>>>>>>> connected to BT controller in the first place.
>>>>>>>>> 
>>>>>>>>> Dedicated PCM lines are used in embedded world and maybe also still in
>>>>>>>>> some mobile segment. I remember that e.g. Nokia N900 had this setup. And
>>>>>>>>> it was quite crazy how it was finally configured... but it worked!
>>>>>>>>> 
>>>>>>>>> But this is nothing for classic x86 laptops with USB bluetooth
>>>>>>>>> controllers on classic intel bluetooth+wifi mPCIe cards where SCO
>>>>>>>>> traffic is routed via HCI (over USB). And not via dedicated PCM pins.
>>>>>>>>> Moreover I think there are not any mainstream laptop which have PCM pins
>>>>>>>>> on mPCIe slots usable for such bluetooth mPCIe cards.
>>>>>>>>> 
>>>>>>>>> For classic desktop / laptop it is needed to deal with fact that SCO
>>>>>>>>> audio is routed via HCI (like A2DP) and therefore support for Enhanced
>>>>>>>>> Setup Synchronous Connection HCI command.
>>>>>>>>> 
>>>>>>>>> AFAIK even for routing SCO over PCM when mSBC hw encoder is used,
>>>>>>>>> Enhanced Setup Synchronous Connection HCI command is required.
>>>>>>>> 
>>>>>>>> So you are saying that we should do PCM over HCI and that would
>>>>>>>> actually work (meaning we have enough bandwidth)?
>>>>>>> 
>>>>>>> This is something which needs to be tested. And without full
>>>>>>> implementation (with control of all parameters) we cannot say YES or NO.
>>>>>>> 
>>>>>>> And if you are aware of bandwidth, Enhanced Setup Synchronous Connection
>>>>>>> HCI command allows you to use also software based CVSD codec. Meaning
>>>>>>> that CVSD encoding/decoding can be done by application and therefore
>>>>>>> decreasing amount of data to transfer to bluetooth adapter.
>>>>>>> 
>>>>>>> As I said this command is needed also if you want to use mSBC hw encoder
>>>>>>> over PCM, so I think usage of Enhanced Setup Synchronous Connection HCI
>>>>>>> command always have benefits to implement it (I have unfinished and
>>>>>>> untested implementation).
>>>>>> 
>>>>>> CVSD is an air codec only. Controller<->Host is PCM in that case.
>>>>> 
>>>>> Hello!
>>>>> 
>>>>> This is not fully truth. You can use also use CVSD between Controller
>>>>> and Host. Enhanced Setup Synchronous Connection HCI allows you to do it.
>>>> 
>>>> so the spec is unclear in case of HCI transport. It could be stipulated that CVSD is also possible. However it is not practical since the controller would have to re-encode in case a different air codec is used. The reality is that all “legacy” devices decided for CVSD air codec and PCM host codec.
>>>> 
>>>> Going into this direction of allowing CVSD as host codec is just a waste of time.
>>> 
>>> Well, people are complaining about CVSD quality and there are still lot
>>> of headsets which support only CVSD. Therefore I see a good reason to
>>> try encode/decode of CVSD in software and check if software encoder or
>>> decoder cannot increase this quality. I'm not saying that it can really
>>> improve it but without testing we do not know. And as I know how poor
>>> are some hardware implementations of codecs (but not all) I would not be
>>> surprised if for some bluetooth adapters this can really increase
>>> quality for CVSD transports... But without real tests we do not know.
>> 
>> I really don’t see how this is going to help. I have no interest in this. I think it is a waste of time.
> 
> It is simple. If hw encoder is poor you can write your own in software.
> Then you can compare audio quality of hw encoder in adapter and software
> encoder in userspace.
> 
> I'm sure that people are interested even in increasing quality of CVSD
> transport and they can spend time on own userspace codec.
> 
> I understand that it does not bring any value for you and it can be a
> waste of time for you.
> 
> But please do not block research in this field which can be done by
> other people independently of you.
> 
> The worst what can happen is that (independent) researcher just confirms
> what you have wrote. But even this would be very positive conclusion!

but I am not adding a new kernel-userspace API so that you can tinker with it only to realize that we then get an unneeded API that I have to support for years to come.

If you want this then do it with your own kernel patches and provide numbers that would show this works and improves certain devices. Unless I see that, I am sticking with my point of view.

>>>>>> Only with mSBC you have both air codec and Controller<->Host running with mSBC.
>>>>> 
>>>>> No, you can use it also with other codecs. With all transparent codecs
>>>>> and CVSD, alaw and ulaw based on capabilities of your bluetooth
>>>>> adapters.
>>>> 
>>>> The case when it is not CVSD, alaw and ulaw is pretty clear written in the spec. Both have to be transparent.
>>> 
>>> Yes, for air part it has to be either: CVSD, ALAW, ULAW or TRANSPARENT.
>>> So all other additional codecs use transparent on AIR part.
>>> 
>>> But on local part it can be also any other codec defined in some
>>> assigned number document.
>> 
>> That is not clearly defined. The Codec_Format is an enumeration that is used in multiple places. I think that table is missing an indication what values are valid for certain HCI commands and protocols. We did this for other assigned numbers as well.
>> 
>> As I said, I see zero benefit of using CVSD as input/output codec over HCI.
> 
> Yes, it is unclear and therefore research in this field by other people
> can be interesting. To know what is reality.
> 
> I'm not saying that you have to use it. My argument is to allow other
> people to do it and do not block them.

I am not blocking you writing kernel patches. I am just not putting them upstream just for sake of it.

>>>> I think that the spec and the assigned numbers document is not really clear in specifying which of the Coding_Format fields apply when HCI transport is used vs external channel.
>>> 
>>> It is months ago when I read specification last time, but I think that
>>> at the time when I read it I understood that also CVSD codec may be used
>>> by local part if is supported.
>>> 
>>>> I would really assume that when the host is running the codec, then it is transparent.
>>> 
>>> This is truth for "Setup Synchronous Connection". But not for "Enhanced
>>> Setup Synchronous Connection". In "Enhanced" version you can have local
>>> codec for host also "CVSD", also "mSBC" and also any other which adapter
>>> returns in the "local codec" list or in "vendor codec" list. And for
>>> local part in "Enhanced" version this is *not* transparent anymore.
>>> 
>>> Of course "Enhanced" version support also "transparent" code and behave
>>> like in classic non-enhanced version.
>> 
>> Read my comment again since I did check the spec. It is super unclear on what values are support for input/output codec format when using HCI transport. I bet you that once you try this, you will see limitation in the controllers and they are just telling you Invalid Parameters.
>> 
>>>> When the codec is offload to the controller, then the host transport is Linear PCM.
>>>> 
>>>> So you I would plan for CVSD<->CVSD<->PCM, Transparent<->{mSBC,LC3}<->PCM, Transparent<->Transparent<->{mSBC,LC3} for the SCO/eSCO cases.
>>> 
>>> You forgot AuriStream codec which is used and heavily supported by lot
>>> of headsets. Just people do not know that is is supported.
>> 
>> But then again, that is Transparent. So Transparent<->Transparent<->{mSBC,LC3,AuriStream,etc}.
> 
> Yes, it is transparent, but with different parameters which needs to be
> passed to Setup Synchronous Connection parameters. And because this
> codec is SW, encoding and decoding is done in software, userspace must
> be able to "tune" parameters for Setup Synchronous Connection command.
> 
> Without it, it is not possible to use AuriStream codec, even it is
> Transparent.
> 
>>> I would really suggest to look at my API for specifying codec parameters
>>> on socket and allow usage of "Enhanced Setup Synchronous Connection".
>>> 
>>> I do not think it is waste of time. At least it allows doing all kind of
>>> test what adapters support and what is the quality of transport.
>> 
>> I am not going to expose the full crazy that is that HCI command to userspace.
> 
> Ok, I understand that you do not like alaw and ulaw codecs. But do not
> block usage of AuriStream. This codec is supported by many headsets and
> has better quality than CVSD (which is currently supported by kernel).
> 
> Also, please keep in mind that alaw and ulaw codecs are
> telecommunication standards and these codecs are still used.
> 
> People leaving in Europe and working in telecommunication sector would
> know that alaw is codec main voice codec for audio PSTN calls and is
> used also in VOIP lines.
> 
> So even if you marked it as legacy, it does not mean that it is not
> used. Yes, it is legacy, but it is still there and tons of voice calls
> in Europe are encoded in alaw.

This argument is mood. They are not used as air codecs with Bluetooth. If you don’t use Wideband speech, it will be CVSD as air codec and nothing else.

> But at least, please do not blok usage of AuriStream codec by Linux
> kernel. People are complaining about bad quality, AuriStream can improve
> it, but this decision just say "we do not want improvement".
> 
> I was open for any discussion how to bring it, but for one year I have
> received any positive reaction how to achieve it. I designed API which
> would allow it but there was no discussion about it, how to either
> improve it or something else.

We can design something to allow tuning transparent setup, but if you want to play with CVSD as host codec, then you are on your own.

Regards

Marcel

Re: Default to HW mSBC on capable controllers ?

[Pali Rohár]

On Tuesday 22 December 2020 22:11:40 Marcel Holtmann wrote:
> > But at least, please do not blok usage of AuriStream codec by Linux
> > kernel. People are complaining about bad quality, AuriStream can improve
> > it, but this decision just say "we do not want improvement".
> > 
> > I was open for any discussion how to bring it, but for one year I have
> > received any positive reaction how to achieve it. I designed API which
> > would allow it but there was no discussion about it, how to either
> > improve it or something else.
> 
> We can design something to allow tuning transparent setup

Great! Can we finally move in this direction please?

Re: Default to HW mSBC on capable controllers ?

[Joakim Tjernlund]

On Mon, 2020-12-21 at 22:07 +0100, Pali Rohár wrote:
> On Friday 18 December 2020 13:32:29 Joakim Tjernlund wrote:
> > There seems to be quite a few USB controllers gaining the BTUSB_WIDEBAND_SPEECH which I guess means HW mSBC
> 
> No, it does not mean mSBC.
> 

I forgot, if BTUSB_WIDEBAND_SPEECH does not mean capable of HW mSBC, what does it mean?

 Jocke

Re: Default to HW mSBC on capable controllers ?

[Pali Rohár]

On Wednesday 23 December 2020 15:41:01 Joakim Tjernlund wrote:
> On Mon, 2020-12-21 at 22:07 +0100, Pali Rohár wrote:
> > On Friday 18 December 2020 13:32:29 Joakim Tjernlund wrote:
> > > There seems to be quite a few USB controllers gaining the BTUSB_WIDEBAND_SPEECH which I guess means HW mSBC
> > 
> > No, it does not mean mSBC.
> > 
> 
> I forgot, if BTUSB_WIDEBAND_SPEECH does not mean capable of HW mSBC, what does it mean?

BTUSB_WIDEBAND_SPEECH flag is just for usb bluetooth adapters. Not for
UART or SDIO bluetooth adapters.

It is a hint set for some bluetooth adapters which are on kernel
whitelist that wideband speech support is possible for them.

mSBC is not the only one codec which has wideband support.

Based on current "whitelist" implementation it does not mean adapters
without this hint are not mSBC capable (e.g. new adapters could not be
on this list) and also there is a theoretical chance that some with this
flag are not capable of mSBC. But this is only theoretical and I think
you can say that BTUSB_WIDEBAND_SPEECH is sufficient for mSBC. But it is
not necessary condition for mSBC (e.g. because of UART or SDIO adapters
or adapters which are not whitelist yet).

I hope to see AuriStream support which is also wideband speech codec but
should work also with some adapters which are not able to provide enough
bandwidth for mSBC.

Re: Default to HW mSBC on capable controllers ?

[Luiz Augusto von Dentz]

Hi Pali, Joakim,

On Wed, Dec 23, 2020 at 7:58 AM Pali Rohár <pali@kernel.org> wrote:
>
> On Wednesday 23 December 2020 15:41:01 Joakim Tjernlund wrote:
> > On Mon, 2020-12-21 at 22:07 +0100, Pali Rohár wrote:
> > > On Friday 18 December 2020 13:32:29 Joakim Tjernlund wrote:
> > > > There seems to be quite a few USB controllers gaining the BTUSB_WIDEBAND_SPEECH which I guess means HW mSBC
> > >
> > > No, it does not mean mSBC.
> > >
> >
> > I forgot, if BTUSB_WIDEBAND_SPEECH does not mean capable of HW mSBC, what does it mean?
>
> BTUSB_WIDEBAND_SPEECH flag is just for usb bluetooth adapters. Not for
> UART or SDIO bluetooth adapters.
>
> It is a hint set for some bluetooth adapters which are on kernel
> whitelist that wideband speech support is possible for them.

Actually it is meant indicate to application that BT_PKT_STATUS can be
used which enables the implementation of PLC (Packet Loss
Concealment), Ive been advocating to change it or just remove it
entirely and move it to be queried with BT_PKT_STATUS.

> mSBC is not the only one codec which has wideband support.
>
> Based on current "whitelist" implementation it does not mean adapters
> without this hint are not mSBC capable (e.g. new adapters could not be
> on this list) and also there is a theoretical chance that some with this
> flag are not capable of mSBC. But this is only theoretical and I think
> you can say that BTUSB_WIDEBAND_SPEECH is sufficient for mSBC. But it is
> not necessary condition for mSBC (e.g. because of UART or SDIO adapters
> or adapters which are not whitelist yet).
>
> I hope to see AuriStream support which is also wideband speech codec but
> should work also with some adapters which are not able to provide enough
> bandwidth for mSBC.



-- 
Luiz Augusto von Dentz

Re: Default to HW mSBC on capable controllers ?

[Marcel Holtmann]

Hi Luiz,

>>>>> There seems to be quite a few USB controllers gaining the BTUSB_WIDEBAND_SPEECH which I guess means HW mSBC
>>>> 
>>>> No, it does not mean mSBC.
>>>> 
>>> 
>>> I forgot, if BTUSB_WIDEBAND_SPEECH does not mean capable of HW mSBC, what does it mean?
>> 
>> BTUSB_WIDEBAND_SPEECH flag is just for usb bluetooth adapters. Not for
>> UART or SDIO bluetooth adapters.
>> 
>> It is a hint set for some bluetooth adapters which are on kernel
>> whitelist that wideband speech support is possible for them.
> 
> Actually it is meant indicate to application that BT_PKT_STATUS can be
> used which enables the implementation of PLC (Packet Loss
> Concealment), Ive been advocating to change it or just remove it
> entirely and move it to be queried with BT_PKT_STATUS.

after we fixed the bug with the SCO packet flags, we might not even need this anymore at all and just enable the error reporting unconditionally.

On a side note, I insisted on calling this WIDEBAND_SPEECH option since we should be hiding details behind a single flag and not spread multiple flags for things that need to be combined into one logical feature anyway.

Regards

Marcel

Re: Default to HW mSBC on capable controllers ?

[Pasi Kärkkäinen]

On Tue, Dec 22, 2020 at 10:13:11PM +0100, Pali Rohár wrote:
> On Tuesday 22 December 2020 22:11:40 Marcel Holtmann wrote:
> > > But at least, please do not blok usage of AuriStream codec by Linux
> > > kernel. People are complaining about bad quality, AuriStream can improve
> > > it, but this decision just say "we do not want improvement".
> > > 
> > > I was open for any discussion how to bring it, but for one year I have
> > > received any positive reaction how to achieve it. I designed API which
> > > would allow it but there was no discussion about it, how to either
> > > improve it or something else.
> > 
> > We can design something to allow tuning transparent setup
> 
> Great! Can we finally move in this direction please?
>

So, Marcel, is this something you're working on, or going to propose?

Or should Pali (or others) propose something for tuning the transparent setup?


Thanks,

-- Pasi

Re: Default to HW mSBC on capable controllers ?

[Pali Rohár]

On Monday 21 December 2020 17:54:56 Luiz Augusto von Dentz wrote:
> Hi Pali,
> 
> On Mon, Dec 21, 2020 at 1:14 PM Pali Rohár <pali@kernel.org> wrote:
> >
> > On Friday 18 December 2020 11:43:32 Luiz Augusto von Dentz wrote:
> > > Hi Joakim,
> > >
> > > On Fri, Dec 18, 2020 at 10:48 AM Joakim Tjernlund
> > > <Joakim.Tjernlund@infinera.com> wrote:
> > > >
> > > > There seems to be quite a few USB controllers gaining the BTUSB_WIDEBAND_SPEECH which I guess means HW mSBC but currently there is no way to select this mode.
> > > > Any idea if one could patch the kernel to default to HW mSBC and user apps like bluealsa/pulseaudio would just use it automatically?
> > >
> > > It is in our plan to support HW offloading, but that doesn't mean all
> > > platforms will be supported since that depends on the PCM lines being
> > > connected to BT controller in the first place.
> >
> > Dedicated PCM lines are used in embedded world and maybe also still in
> > some mobile segment. I remember that e.g. Nokia N900 had this setup. And
> > it was quite crazy how it was finally configured... but it worked!
> >
> > But this is nothing for classic x86 laptops with USB bluetooth
> > controllers on classic intel bluetooth+wifi mPCIe cards where SCO
> > traffic is routed via HCI (over USB). And not via dedicated PCM pins.
> > Moreover I think there are not any mainstream laptop which have PCM pins
> > on mPCIe slots usable for such bluetooth mPCIe cards.
> >
> > For classic desktop / laptop it is needed to deal with fact that SCO
> > audio is routed via HCI (like A2DP) and therefore support for Enhanced
> > Setup Synchronous Connection HCI command.
> >
> > AFAIK even for routing SCO over PCM when mSBC hw encoder is used,
> > Enhanced Setup Synchronous Connection HCI command is required.
> 
> So you are saying that we should do PCM over HCI and that would
> actually work (meaning we have enough bandwidth)? From power point of
> view this makes very little sense imo, since all the cycle we save on
> no encoding we probably lose with more data to transmit

I do not think so that this applies to all setups. And even if you have
truth then at least CPU usage would be lower and CPU can be used for
additional work. So I do not think that usage of HW encoder/decoder
makes very little sense. In any case it can offload work from CPU.