On Sun, 2019-06-09 at 21:41 +0200, Pali Rohár wrote: > On Sunday 09 June 2019 08:51:38 Tanu Kaskinen wrote: > > 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. > > In my opinion such module (or integrated into sbc codec code) should be > part of upstream pulseaudio. > > Pulseaudio has currently some logic for decreasing SBC bitpool to handle > problems when bluez socket does not accept samples too fast. > > IIRC there is already reported bug that this logic does not increasing > SBC bitpool and I agree that this is something which should be fixed in > PA -- not in external process. > > And proposed solution to automatically adjust SBC bitpool based on > environment is just improvement to currently implemented algorithm which > decrease SBC bitpool. If the bitpool policy can be improved in PulseAudio in such a way that external control API won't be needed, then that seems like a preferable approach indeed. Frédéric said "I think this can not be achieved by an algorithm inside PA daemon". I guess you want some more evidence for that? One part of the system description was that the bitpool setting could be applied globally for all devices, or subsets of devices. An algorithm in PulseAudio can only act locally. Do you think applying the bitpool on multiple devices in concert is an unnecessary requirement? > > > 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. > > Currently PA codec API has function to "decrease" quality (function > reduce_encoder_bitrate). So technically we could export this function > and then introduce also function to "increase" quality. > > But is there any other A2DP codec which is not fixed and support VBR / > runtime quality settings? I'm not aware of such codecs. -- 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
