[pulseaudio-discuss] Bluetooth codec selection

[Georg Chini]

On 08.01.20 12:35, Pali Rohár wrote:
> On Tuesday 07 January 2020 21:57:40 Georg Chini wrote:
>> On 07.01.20 19:37, Pali Rohár wrote:
>>> Hello!
>>>
>>> My A2DP patch series which adds support for more A2DP codecs is still in
>>> review state, but Tanu about year ago wrote that do not like my proposal
>>> with usage of PA profiles for selecting A2DP codec. Because nobody for
>>> last year come up with another option how to solve this problem and
>>> because without it is not possible to add support for other codecs it
>>> means that pulseaudio is stucked and has no way to improve A2DP support.
>>>
>>> So here I'm adding another proposal how to handle multi-codec support
>>> for bluetooth in pulseaudio. But first description of our problem:
>>>
>>> Currently we have following profiles for bluetooth card:
>>>
>>> * headset_audio_gateway
>>> * headset_head_unit
>>> * a2dp_source
>>> * a2dp_sink
>>>
>>> If we look at HW level of HSP/HFP profiles they may supports following
>>> codecs: CVSD, mSBC, AuriStream. All are bidirectional, synchronous.
>>> Moreover encoding from PCM stream to codec data may be done at HW level
>>> (bluetooth adapter) or on SW level (pulseaudio). Currently encoding to
>>> CVSD is done at HW level and encoding to mSBC at SW level. But e.g. new
>>> Thinkpads has bluetooth adapters which can do mSBC-encoding at HW level
>>> and theoretically pulseaudio could just pass PCM samples to BT without
>>> need to use any software sbc encoding library (*).
>>>
>>> And if we look at A2DP profiles it is quite a bit complicated. Every
>>> "A2DP codec" is either one-way (source or sink) or is bi-directional
>>> (but it is rare and most devices does not support them). Plus every
>>> "A2DP codec" may support more "codec profiles", so e.g. we have SBC-MQ
>>> or SBC-HQ. And bidirectional "A2DP codecs" may use different "audio
>>> codec" for one directional and different for back directional (e.g.
>>> A2DP codec aptX-LL uses aptX codec for playing and SBC codec for
>>> recording).
>>>
>>> Result is: "SBC" codec is supported in "headset_head_unit" PA profile
>>> (as mSBC"), it is supported also in "a2dp_sink" PA profile when "A2DP
>>> SBC" codec is used and also in "a2dp_source" PA profile when "aptX-LL"
>>> codec is used.
>>>
>>> So adding a new API which sets codec on PA bluetooth card is not enough.
>>>
>>> I would propose following API:
>>>
>>> Add support for pulseaudio "sub-profiles". For every pulseaudio profile
>>> it would be possible to register sub-profile and applications via
>>> pulseaudio API would be able to change sub-profile of some PA card (if
>>> currently selected PA profile would support it).
> Just to make it clear, by "applications" I mean mixer setting
> applications (e.g. pactl, pavucontrol, kmix, gnome settings, ...).
>
>>> Plus adds a two new profiles:
>>> * a2dp_source_with_backchannel
>>> * a2dp_sink_with_backchannel
>>>
>>> For music playback in most cases is useful only profiles without
>>> backchannel to maximize bandwidth. And because A2DP codecs with
>>> bachannel does not fit into HSP profiles it make sense to have them in
>>> separate profile. In most cases A2DP profile with backchannel is the
>>> best way for VOIP (as it has microphone recording support), so bluetooth
>>> policy plugin would be extended to use also this profile for VOIP.
>>>
>>> Sub-profiles for bluetooth PA card would be following:
>>>
>>> * headset_audio_gateway
>>>     - CVSD (hardware)
>>>     - mSBC (software)
>>>     - mSBC (hardware)
>>>     ...
>>> * headset_head_unit
>>>     - same as in headset_audio_gateway
>>> * a2dp_source
>>>     - SBC-LQ
>>>     - SBC-MQ
>>>     - SBC-HQ
>>>     ..,
>>>     - faststream without backchannel
>>>     - aptX
>>>     - aptX-HD
>>>     - aptX-LL without backannel
>>>     - LDAC
>>>     ...
>>> * a2dp_sink
>>>     - same as in a2dp_source
>>> * a2dp_source_with_backchannel
>>>     - faststream with backchannel
>>>     - aptX-LL with backchannel
>>> * a2dp_sink_with_backchannel
>>>     - same as in a2dp_source_with_backchannel
>>>
>>> So sub-profile would be one specific configuration of codec. In HSP/HFP
>>> there would be two sub-profiles for every codec (one for software
>>> encoding, one for hardware encoding). In A2DP it may be various. E.g.
>>> for "SBC profiles" there would be one sub-profile for every SBC
>>> configuration. For faststream codec there would be two, one with
>>> backchannel, one without. Default sub-codec selection would be up to
>>> the pulseaudio module. And applications (pactl / pavucontrol / ...)
>>> would be able to change PA sub-profile in similar way how they can do it
>>> for PA profiles.
>>>
>>> Of course some sub-profiles does not have to be supported (e.g. mSBC in
>>> hardware encoding) and in these cases pulseaudio would not announce
>>> these unsupported sub-profiles.
>>>
>>> What do you think about this my proposal?
>>>
>>> Tanu, is this acceptable for you?
>>>
>>> Basically it is needed only to add APIs for applications to:
>>> * get current sub-profile of card
>>> * get list of all sub-profiles for specific profile
>>> * change sub-profile of card
>>>
>>> I'm not saying how would API look like. I'm open for implementation
>>> details... I can imagine that we can extend PA protocol or use messaging
>>> API for it or anything else...
>>>
>>>
>>> (*) - currently Linux kernel blocks this usage of mSBC HW encoding and
>>> force userspace to do whole encoding at application level (in
>>> pulseaudio).
>>>
>> I think your proposal looks good. I agree that we need new profiles for A2DP
>> with backchannel
> Ok
>
>> and your sub-profiles basically implement codec switching
>> (or codec parameter switching in some cases). Sub-profile switching could
>> be implemented using !51, which then allows control via pactl or pacmd.
>> In pavucontrol, sub-profiles could be displayed in a separate drop down box.
> Yes, this would work.

At least Tanu or Arun should also give an OK before you start any
work on that approach.

>
> So can we make progress here? What is blocking merging message API?

Tanu still has to review part of the series.

>
> And if I reimplement my A2DP patch series with "subprofiles" via message
> API, would it be finally merged into pulseaudio? Or I would need to wait
> another two years? My first submission of A2DP patch series is from 2018!
>
Well, the first version of the messaging API was posted in July, 2017
and other of my patches that are still not reviewed date back to 2016.
Like you, I complain occasionally but we are low on review bandwidth,
so everything takes its time.
However, your patch series is pretty high in our priority list and I
committed to review it, so I guess you will not have to wait for years.