[pulseaudio-discuss] [RFC 0/2] Add dynamic configuration of SBC bitpool
frederic.danis at collabora.com
Thu May 23 14:12:18 UTC 2019
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
>>>> In a crowded environment this can allow to limit interference between source
>>>> and headphones.
>>>> This needs "Message API v2" patches from Georg Chini 
>>>> I am currently not sure in patch 2 where should occur the SBC bitpool apply.
>>>> Any comments appreciated.
>>>>  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
>> I've sent this RFC with minimal dependency on waiting patches to start
>> getting some feedback about it.
>> With your patches, I have to use the "SBC (Automatic Quality)" profile to be
>> able to change the SBC bitpool.
>> Do you know if there is a way to set it as preferred profile for new
> 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.
>>> 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
>>> Anyway, correct behavior of SBC codec in automatic mode should
>>> automatically increase or decrease SBC bitpool based on available
>> The idea should be to have an external application getting information
> This is way to the hell.
>> 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.
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, …
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the pulseaudio-discuss