Re: [RFC 0/2] Add dynamic configuration of SBC bitpool

[Frédéric Danis <frederic.danis@xxxxxxxxxxxxx>]

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

_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss