[pulseaudio-discuss] [RFC 0/2] Add dynamic configuration of SBC bitpool

Sun Jun 9 05:51:38 UTC 2019

On Mon, 2019-06-03 at 16:01 +0200, Pali Rohár wrote:
> Hi!
> 
> On Thursday 23 May 2019 16:12:18 Frédéric Danis wrote:
> > Hi Pali,
> > 
> > On 17/05/2019 16:38, Pali Rohár wrote:
> > > On Friday 17 May 2019 16:26:30 Frédéric Danis wrote:
> > > > Hi Pali,
> > > > 
> > > > On 17/05/2019 15:51, Pali Rohár wrote:
> > > > > On Friday 17 May 2019 15:45:10 Frédéric Danis wrote:
> > > > > > This series of patch allows to manage the bandwidth used by an A2DP source
> > > > > > using SBC encoder by adding ability to change the bitpool dynamically during
> > > > > > runtime.
> > > > > > In a crowded environment this can allow to limit interference between source
> > > > > > and headphones.
> > > > > > 
> > > > > > This needs "Message API v2" patches from Georg Chini [1]
> > > > > > 
> > > > > > I am currently not sure in patch 2 where should occur the SBC bitpool apply.
> > > > > > 
> > > > > > Any comments appreciated.
> > > > > > 
> > > > > > [1] https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/51
> > > > > Hi! I would suggest to wait until my patches for extending A2DP codecs
> > > > > is reviewed and merged. You can find them in email with subject
> > > > > "[PATCH v10 00/11] Bluetooth A2DP codecs"
> > > > Tanu Kaskinen has already pointed them to me and I have a version using
> > > > them.
> > > > I've sent this RFC with minimal dependency on waiting patches to start
> > > > getting some feedback about it.
> > > Ok.
> > > 
> > > > With your patches, I have to use the "SBC (Automatic Quality)" profile to be
> > > > able to change the SBC bitpool.
> > > Ok.
> > > 
> > > > Do you know if there is a way to set it as preferred profile for new
> > > > connections?
> > > So.. I do not think that "SBC (Automatic Quality)" should be used as
> > > default/preferred profile.
> > > 
> > > Lot of people are complaining about bad quality of the bluetooth a2dp
> > > implementation in linux... And the solution is to use SBC UHQ mode if is
> > > available -- so to stop using SBC High Quality (and automatic quality).
> > > In most cases SBC UHQ is possible to use only via DualChannel mode as
> > > the highest possible bitpool value for JointStereo mode in most cases is
> > > not enough for UHQ.
> > 
> > I understand your point of view, but my tests with SBC UHQ mode in an
> > environment with interferences may increase sound quality but with audio
> > dropouts. Which is not really better.
> 
> Generally there are 3 problems:
> 
> 1) Some codecs have fixed parameters, no way for "low quality".
> 
> 2) What should be the default codec?
> 
> 3) What should happen when current codec is "unusable" in current
>    environment?
> 
> Main objection against usage of SBC is that you do not know what
> configuration and parameters are in use. So people rather want to have
> aptX which has only one quality, no dynamic change.
> 
> This is also reason for introducing SBC profiles, to have ability to
> compare codec quality.
> 
> One of the solution is: For each device remember last used codec/profile
> and use it as default. If there is no remembered codec/profile (e.g.
> because it is first time connection) then choose the codec/profile with
> highest possible quality. If user is unsatisfied he should be able to
> change it.
> 
> > > > > In this patch series is also big rework of SBC codec, to support e.g.
> > > > > UHQ mode and your changes would introduce new conflicts with that patch
> > > > > series.
> > > > > 
> > > > > Anyway, correct behavior of SBC codec in automatic mode should
> > > > > automatically increase or decrease SBC bitpool based on available
> > > > > bandwidth.
> > > > The idea should be to have an external application getting information
> > > This is way to the hell.
> > > 
> > > > about
> > > > the radio environment like the number of Bluetooth devices (A2DP sources and
> > > > sinks, and other devices), link quality, WiFi usage, ... to be able to
> > > > dynamically change the bitpool to be used.
> > > I do not think that this would work reliable even when implemented. Plus
> > > having another external entity which would control internal settings of
> > > A2DP transfer is the worst solution. People would just start more
> > > complaining that subjective quality is not good. And debugging another
> > > external application, or more figuring out how is configured would just
> > > complicate many more things.
> > 
> > What I would like to achieve is to be able to control the SBC bitrate of up
> > to 300 BT transmitters in a noisy and possibly RF perturbed environment, for
> > which I can watch the statistics for dropouts, and if it gets too high,
> > reduce the quality either globally, or across a physically-adjacent set of
> > transmitters. I think this can not be achieved by an algorithm inside PA
> > daemon.
> 
> Understood.
> 
> But I think it would be better if this is implemented as pulseaudio
> module, not as external application. Similarly like there is already
> bluetooth policy module which switch between A2DP and HSP profiles for
> VOIP automatically. So similarly module for controlling SBC quality like
> you described can be implemented.

Since there's no stable API for modules, a PulseAudio module is a
viable strategy only if the module is accepted upstream (or if you're
willing to maintain a PulseAudio fork). The use case described here
sounds very specialized, so it might be hard to come up with a module
that would be widely applicable enough to be accepted upstream.

> I do not like idea for exporting codec specific configuration out of
> pulseaudio process. As particular settings depends on codec and API was
> designed to be codec-independent. Plus whole work which you described is
> for SBC codec.

If the only thing needed is an API to set the bitpool value when using
the "automatic quality" SBC, I don't see big problems with that. Yes,
it's a bit niche API, but it shouldn't affect the generality of the
rest of the API.

> > I'm not intending to have "btsbcqualityd" running on everyone's desktop.
> > 
> > > SBC bitpool indirectly specify SBC packet size. In my opinion bitpool
> > > should be controlled directly by pulseaudio based on socket latency and
> > > socket state, packet loss, how is kernel able to transmit packets...
> > 
> > AFAIK there is not so many information available from the Bluetooth side
> > regarding socket latency, packet loss, …
> 
> You have information if socket is ready for a new data. Also you can
> measure delays or calculate how many bytes were already dropped.

I guess the question is can PulseAudio do as good a job of controlling
the bitpool as "btsbcqualityd". Insisting that PulseAudio decides the
bitpool policy works only if PulseAudio can implement the required
policy by itself.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk