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

Sun Jun 9 19:41:43 UTC 2019

On Sunday 09 June 2019 08:51:38 Tanu Kaskinen wrote:
> 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.

In my opinion such module (or integrated into sbc codec code) should be
part of upstream pulseaudio.

Pulseaudio has currently some logic for decreasing SBC bitpool to handle
problems when bluez socket does not accept samples too fast.

IIRC there is already reported bug that this logic does not increasing
SBC bitpool and I agree that this is something which should be fixed in
PA -- not in external process.

And proposed solution to automatically adjust SBC bitpool based on
environment is just improvement to currently implemented algorithm which
decrease SBC bitpool.

> > 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.

Currently PA codec API has function to "decrease" quality (function
reduce_encoder_bitrate). So technically we could export this function
and then introduce also function to "increase" quality.

But is there any other A2DP codec which is not fixed and support VBR /
runtime quality settings?

> > > 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.

I still think that pulseaudio, as direct user of bluez, has more
information as any other external process, which do not have access to
bluez socket.

Also I do not see reason why anything which can be implemented in
external process, could not be implemented directly in pulseaudio...

-- 
Pali Rohár
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20190609/8d8ab8ec/attachment.sig>