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

[Frédéric Danis]

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.

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

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, …

Fred
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20190523/959d1f16/attachment.html>