[pulseaudio-discuss] Bluetooth HSP and HFP support in pulseaudio

[Georg Chini]

On 29.04.20 00:03, Pali Rohár wrote:
> On Tuesday 28 April 2020 21:52:55 Georg Chini wrote:
>> On 28.04.20 21:06, Pali Rohár wrote:
>>> On Tuesday 28 April 2020 20:50:33 Georg Chini wrote:
>>>> Personally I don't see a problem to remove the AG role support from
>>>> the ofono backend because nobody uses it. What I proposed earlier
>>>> - allow hsphfpd to disable the HFP HS role and keep a "legacy" ofono
>>>> backend for the HFP HS role - should not be that hard to implement
>>>> compared to all the time and work you already invested and it would
>>>> help us to keep users happy.
>>> As I said, I have no problems with allowing to disable particular
>>> profile from hsphpfd. But the way how ofono has it implemented, when it
>>> is not possible to unregister specific profile and it always register
>>> master SCO listening socket, it means that you cannot have two
>>> applications which would implement or register HSP or HFP profile for
>>> audio, independently of the role.
>>>
>>> So you cannot use ofono's HFP AG role for connecting mobile phone and
>>> other application (e.g. hsphpfd) for using HFP HS role for connecting
>>> headset.
>> Sorry, forgive my ignorance. You can switch off ofonos AG role,
>> in that case it will only register the HS role with bluetoothd and
>> only react to connection attempts with the specific UUID.
>> Is it not possible that ofono registers one role and hsphfpd the
>> other?
> Via --noplugin you specify which ofono plugins would not be loaded. So
> you can instruct ofono to not register HF or AG role of HFP to
> bluetoothd, which cause that bluetoothd does not create new RFCOMM
> connection for particular profile UUID. So registering / unregistering
> of UUIF can be done by restarting ofono with different parameters.
>
> But for HSP and HFP this is not enough! SCO listening master socket is
> created by ofono if at least one of HF or AG role plugin is loaded. And
> you cannot control this behavior as ofono does not have API for it.
>
>> And even if it is not possible and you can't use both at the same
>> time (which would be a pity)
> No it is not possible. It is even not possible to have one application
> with HSP HS and one with HFP AG (see difference HSP and HFP, even
> different profile is not possible).

That is definitely possible. This is how I have had working basic
headset support + mobile support for the last couple of years.
After switching off the AG role in ofono, a mobile will connect
to HFP provided by ofono while a headset connects to HSP
provided by the native backend. And actually I don't want to loose
this functionality (though at the moment the new board I have
has a broken USB3 implementation so that I cannot use BT at all).

>
> As I wrote is exactly same as if two applications want to listen on TCP
> port 1234 and both applications wants to accept only socket with
> specific parameters which can be deduced only after accepting socket.
>
> SCO sockets are not managed by bluetoothd daemon, but by target agent
> application which implements that particular profile.
>
>> we still have to respect if a user
>> thinks that for him a working implementation for his mobile is
>> more important than good headset support and therefore prefers
>> the ofono backend over any other backend.
>>> So what you want is currently impossible. You have to first fix ofono
>>> daemon, design and export API for it and then implement other side to
>>> use that API.
>>>
>>> And I'm explaining again that this is reason why to have one central
>>> daemon which would implement HSP and HFP profiles and proxies needed
>>> support / sockets to target applications.
>>>
>>> If one application is stealing listening sockets and cannot be
>>> configured to not do it, other applications are just out of luck.
>>>
>>> It is same as if two UDP or TCP applications wants to listen on port
>>> 1234 and both want to accept new connections. Without full cooperative
>>> environment it does not work. hsphfpd daemon is there to accept new
>>> connections from both RFCOMM and SCO sockets and do all needed stuff
>>> with it (pass to other application, or process data on it directly).
>>>
>> The point is, that the applications that support the new hsphfpd
>> not yet exist, so we have at least to support the status quo until
>> there is some alternative.
> Are there other modem softwares? I can write e.g. simple application for
> hsphfpd which exports socket as tty device (via pts kernel interface).
> If there are working modem software which can use tty modem then could
> access also modem exported in this way.
>
Well, ofono provides support for all kinds of modems, so it should
be possible still to use ofono. Actually the main target of ofono are
hardware modems and the HFP stuff is more like an add-on.