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
