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. 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. > 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. -- Pali Rohár pali.rohar@xxxxxxxxx _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
