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. So can we make progress here? What is blocking merging message API? 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! -- Pali Rohár pali.rohar@xxxxxxxxx _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
