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 Thursday 17 October 2019 16:11:26 Tanu Kaskinen wrote:
> On Thu, 2019-10-17 at 14:55 +0200, Pali Rohár wrote:
> > On Thursday 17 October 2019 15:52:00 Tanu Kaskinen wrote:
> > > On Tue, 2019-10-08 at 18:29 +0200, Pali Rohár wrote:
> > > > Automatic SBC profile is not going to be changed. It is there to support
> > > > all devices without any tweaks. ValdikSS already did more tests and
> > > > there are devices which do not work with higher SBC bitpool. So
> > > > increasing max value of bitpool in Automatic SBC profile would lead to
> > > > broken support for these devices and therefore regressions.
> > > > 
> > > > As Automatic SBC profile is the only one available for systems where
> > > > codec switching is not supported, it would mean complete regression as
> > > > these devices completely stops working on those systems.
> > > > 
> > > > Upgrading either pulseaudio or bluez must not lead to problem that some
> > > > bluetooth devices stop working (if they worked before upgrade).
> > > > 
> > > > So no, there would not be any changes in Automatic SBC profile. This one
> > > > should stay untouched, to make it always working with all existing
> > > > devices without any regression.
> > > 
> > > I wasn't aware that advertising the XQ settings during negotiation
> > > breaks some devices. I guess this means that JP Guillaume's SBC XQ
> > > patch can't be accepted, assuming that we value avoiding regressions
> > > more than the improved quality for most headsets?
> > 
> > In this patch series I'm reworking and proposing also XQ profiles at
> > separate endpoints. So in case XQ is broken for paricular device, with
> > codec switching API, user would be able to switch back to automatic SBC
> > profile (on different SEP) which should stay as it is in current
> > version, which is working with all devices.
> 
> Yes, but what about JP Guillaume's patch, which is a simple way of
> achieving XQ support before your patches have been accepted? I planned
> to review it first (because he asked), but now it looks like that may
> not be a good idea (I don't want regressions).

With that "simple way" patch there would be regressions for "broken"
devices. That is the reason why codec switching from bluez side is
needed and having separate SEPs for XQ. So Automatic profile (current
one) could be freezed and would be used like before for all devices.

> > > Here's that patch: 
> > > https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/177
> > > 
> 

-- 
Pali Rohár
pali.rohar@xxxxxxxxx
_______________________________________________
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