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

[Hyperion]

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"

Just my 2 cents
JP

17.10.2019, 15:14, "Pali Rohár" <pali.rohar at gmail.com>:
> 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 at gmail.com