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 _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
