[pulseaudio-discuss] Proposal for a new API and usage of Bluetooth HSP and HFP profiles on Linux
pali.rohar at gmail.com
Mon Dec 9 11:07:06 UTC 2019
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
> 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
> 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:
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
hsphfpd is central point for all HSP and HFP related operations and
> 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 &
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
> * 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
> * 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...
pali.rohar at gmail.com
More information about the pulseaudio-discuss