Re: [PATCH v13 10/10] bluetooth: policy: Treat bi-directional A2DP profiles as suitable for VOIP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, 2019-10-19 at 17:20 +0200, Pali Rohár wrote:
> On Friday 18 October 2019 15:29:43 Tanu Kaskinen wrote:
> > On Thu, 2019-10-17 at 15:34 +0200, Hyperion wrote:
> > > Regression would mean that some devices can't connect anymore : this
> > > won't happen if a workaround is provided, and this workaround won't
> > > be used often.
> > > 
> > > Most (99% ?) of the devices will work correctly with my patch (many
> > > of them in XQ mode, and some in legacy mode because they will fall
> > > back to legacy bitpool during negociation)
> > > 
> > > The remaining (1% ?) : will need a simple boolean swicth in one of
> > > the PA config files to restrict negociation to legacy bitpool (a
> > > module option ? or daemon.conf ?).
> > > 
> > > I think it's really "simple", efficient, and not dependent of any
> > > upcoming Bluez feature.
> > > 
> > > "The complex solution is always the best until one find a simpler one"
> > 
> > I don't know the number of users who use bluetooth headsets with
> > PulseAudio, but even just 1% regression rate can mean quite a few
> > unhappy users. When your headset suddenly stops working, it's not
> > trivial to figure out that you may need to pass a special argument to
> > module-bluetooth-discover in order to make it work again.
> > 
> > It would be better to have a module argument to enable the XQ settings.
> 
> Main question, do we really need this special "settings"? Because my
> patch series introduce also SBC XQ profile and basically replaces above
> module parameter, by runtime configuration.
> 
> For me above solution looks like a hack. It adds some module parameter
> for tweaking configuration. And what would happen with that parameter
> after we have "proper" support for multiple codecs? Do we need to
> maintain backward compatibility? Or would we remove that configuration
> and therefore revert to state prior existence of new module parameter
> (which is current situation)?

After your patches there's still the "automatic bitpool" mode
available, right? To me it seems that the new option discussed here
would still be useful, if there are users who prefer to use the
automatic bitpool mode.

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




[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux