Re: Bluetooth: Allow to use configure SCO socket codec parameters

[Aleksandar Kostadinov <akostadi@redhat.com>]

Luiz Augusto von Dentz wrote on 16.05.20 г. 2:08 ч.:
> Hi Andrew, Aleksandar,
> 
> On Fri, May 15, 2020 at 3:46 PM Andrew Fuller <mactalla.obair@gmail.com> wrote:
>>
>> On Thu, 14 May 2020 at 13:09, Aleksandar Kostadinov <akostadi@redhat.com> wrote:
>>>
>>> Pali Rohár wrote on 20.04.20 г. 2:49 ч.:
>>> <...>
>>>> Please let me know what do you think about it. Thanks
>>>
>>> <...>
>>> Thus I and I assume all headphones users will appreciate very much any
>>> support to get things moving forward.
>>
>> To add to what Aleksandar said, a number of us would be more than
>> willing to help out in any way we can.  Certainly myself, but I expect
>> a number of others, too.  We have bluetooth cards in our computers
>> with wideband speech support.  We have bluetooth headsets with
>> wideband speech support.  Many of the links in the chain are in place.
>> If we can continue building that chain then we can have a higher
>> quality experience in this era of teleconferencing in particular.
>>
>> So if there's anything we can lend a hand with, then please let us
>> know and we can see this through.
> 
> Just to be clear here, WBS is already supported what is not supported
> is hardware based codecs, we spend a lot of time enabling WBS on oFono
> but it looks like people are now trying to come with their own
> solutions and complaining about lack of WBS is not really justified
> since the combination of BlueZ + oFono has been in use by the car
> industry for years but desktop folks has not been interested in a
> proper HFP solution so instead we have modem manager, network manager,
> etc, which doesn't even cover all desktop use cases properly as you
> are experience first hand here.

Hi Luiz. I'm not sure arguing on no-technical details here will help.
Still I feel it is important to say that I don't find it justified to
call it *complaining* when somebody is proposing patches which
apparently enable missing functionality and avoid necessity for running
with root privileges.

Now if patch is bad on the technical level, that would be valid point to
reject it. I see Pali trying to address any raised concerns though so I
hope it is alright.

But rejecting the patches on premises that it is not necessary for
solution X and blocking any alternative solutions is IMO unfair.

The needs of car industry are very different from the needs of desktop
users. I'm not a kernel or bluetooth developer but as a user of Network
Manager (that you gave as an example) I can say that it changed a lot
making network management at single point and changing networks easily
while moving around. I've been a network admin in the past and it has
not been a problem to only use static network setup. As a laptop user
though things dramatically changed.

Same goes with Pulse audio/ALSA. While everything could be done with
ALSA it has been much harder and up to the skills of a very few people
to manage audio inputs/outputs/redirection properly. Certainly since
Pulse became stable I never missed asoundrc.

Thus for users it is important what desktop developers are providing.
While we can assume they are all idiots doing things in all the wrong
ways, I'd rather prefer to think they may have a point when choosing
certain technology over another.

So I'm asking anybody that it depends on, to look from the desktop user
perspective and help move this forward.

Thank you.