[pulseaudio-discuss] Proposal for a new API and usage of Bluetooth HSP and HFP profiles on Linux

[Pali Rohár]

Hi George!

On Monday 09 December 2019 11:43:08 George Kiagiadakis wrote:
> In general, I agree that HFP/HSP AT protocol handling is something that
> the audio daemons should not have to worry about. However, I am
> concerned with the level of fragmentation that exists in the bluetooth
> stack.
> 
> At the moment, the best case scenario is that we have 2 processes
> involved in bluetooth audio (in the case where we route directly to/from
> the speakers & microphone of the linux host in question):
> 
>   bluez5 <-> pulseaudio
> 
> With pipewire & bluez-alsa, we have 3 processes:
> 
>   bluez5 <-> pipewire bluetooth session <-> pipewire daemon
> 
>   bluez5 <-> bluez-alsa <-> alsa application

Yes, that is truth.

> The 3 process separation here happens so that the bluetooth codecs run
> in the process that sits in the middle. This avoids having to care about
> codecs on the right side and also avoids slowing down the pipewire
> daemon (so that it can still do low-latency audio processing)
> 
> When ofono comes into play, we increase this by 1:
> 
>    bluez5 <-> ofono <-> pulseaudio
> 
>   bluez5 <-> ofono <-> pipewire bluetooth session <-> pipewire daemon
> 
>   bluez5 <-> ofono <-> bluez-alsa <-> alsa application

Yes.

> With your proposal, we have one more:
> 
>    bluez5 <-> hfphspd <-> ofono <-> pulseaudio
> 
>   bluez5 <-> hfphspd <-> ofono <-> pipewire bluetooth session <->
> pipewire daemon
> 
>   bluez5 <-> hfphspd <-> ofono <-> bluez-alsa <-> alsa application

No, this is not how hsphpfd is suppose to work. Look at design & API:
https://github.com/pali/hsphfpd-prototype/blob/prototype/hsphfpd.txt

ofono would be there only in agent role, similar like audio daemon
(pulseaudio/pipewire/bluez-alsa). So it would look like:

              +---- <-> ofono
              |
bluez5 <-> hsphfpd
              |
              +---- <-> pulseaudio / pipewire / bluez-alsa

You can connect / disconnect ofono without loosing audio functionality.
(Or connect / disconnect audio daemon without loosing telephony modem
functionality.)

hsphfpd is central point for all HSP and HFP related operations and
applications.

> And it can become even more crazy when you do ugly hacks like what I
> have done in Automotive Grade Linux, where I use bluez-alsa for its
> codec implementation & HFP/HSP handling, and then route the audio using
> a gstreamer-based helper process to the pipewire daemon process
> (temporarily, to workaround issues in the pipewire native implementation):
> 
>   bluez5 <-> hfphspd <-> ofono <-> bluez-alsa <-> gstreamer helper <->
> pipewire daemon

With hsphfpd involved, you would never talk with ofono. Also ofono is
not required for this setup.

> Instead of all of this crazy context switching, what I would prefer to
> see is a standalone component library that someone could combine in a
> single process to get things done. This would:
> 
> * avoid re-implementing all kinds of stuff over and over in different
> audio daemons (we do have 3 implementations atm: pulseaudio, pipewire &
> bluez-alsa)

HSP/HFP AT commands needed for audio handling are already designed to be
handled by hsphfpd daemon. Please look at details.

> * prevent people like me from doing ugly hacks to get work done
> * improve collaboration between all the different people that care about
> the bluetooth stack instead of having them antagonize each other

This is reason why I started this discussion :) and proposed my hsphfpd
daemon.

> * avoid the context switching overkill; we should only have 1 process
> between bluez and the audio daemon / solution, imho

There is no context switching in hsphfpd design once audio connection is
established. From hsphfpd you get native audio SCO socket, so audio is
not routed throw hsphfpd nor bluez daemons. Socket directly pass data to
kernel.

> * potentially allow people to use some components in combination with a
> proprietary bluetooth stack instead of bluez (a strong requirement in
> the automotive industry at the moment, at least)

The only what is needed is that "other stack" just export DBus interface
for registering HSP and HFP profiles according to bluez documentation.
Then hsphfpd would work with that bluetooth "other stack".

> I imagine that this component library would include:
> 
> * bluetooth audio codecs

AT commands are covered by hsphfpd. Encoding / decoding of data is up to
the application agent. Please look into hsphfpd.txt document.

But creating a library which would do encoding and decoding of audio
data and acts as a hsphfpd audio application agent is possible. If other
projects want to use it (e.g. pulseaudio, bluez-alsa, pipewire, jack) we
can start a separate discussion about API of such library. I guess that
more audio daemons would be different requirements and to be usable in
all projects we need to cover all of them.

> * HFP/HSP commands handling

This is already covered by hsphpfd.

> * telephony handling

In hsphfpd this is exported to external telephony agent. Possibly ofono
or modem manager (whatever project will implement needed API and
connects to hsphfpd daemon).

> * exposure of common D-Bus APIs for side-channel things like power
> management or phone dialing

This is part of hsphfpd daemon, please look at hsphfpd.txt if it covers
your needs. Btw, phone dialing is part of telephony handling.

> ... and then every downstream user (pulse, pipewire, bluez-alsa, ...)
> could reuse these components and implement the rest of the routing /
> management logic in their own daemon.
> 
> My two cents...
> 
> Regards,
> George

-- 
Pali Rohár
pali.rohar at gmail.com