Re: Default to HW mSBC on capable controllers ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx> 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@xxxxxxxxxxxx> 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.



[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux