Hello!

I'm sending this email to relevant mailing lists and other people who
could be interested in it. (I'm not subscribed to all of ML, so please
CC me when replying).


I would like to open a discussion about a completely new way of handling
Bluetooth HSP and HFP profiles on Linux. These two profiles are the only
standard way how to access microphone data from Bluetooth Headsets.


Previously in bluez4, HFP profile was implemented by bluez daemon and
telephony HFP functionality was provided by either dummy modem, ofono
modem or by Nokia's CSD Maemo modem.

In bluez5 version was modem code together with implementation of HFP
profile removed. And let implementation of HSP and HFP profiles to
external application.

Currently HSP profile is implemented in pulseaudio daemon to handle
microphone and Bluetooth speakers. HFP profile is not implemented yet.


HSP and HFP profiles use AT modem commands, so its implementation needs
to parse and generates AT commands, plus implement needed state machine
for it.

And now problem is that last version of HFP profile specification is too
complicated, plus Bluetooth headsets vendors started to inventing and
using of own custom extensions to HFP profile and AT commands.

Main problem of this "external" implementation outside of bluez is that
only one application can communicate with remote Bluetooth device. It
is application which received needed socket from bluez.

So in this design if audio daemon (pulseaudio) implements HFP profile
for processing audio, and e.g. power supply application wants to
retrieve battery level from Bluetooth device, it means that audio daemon
needs to implement also battery related functionality.

It does not make sense to force power supply daemon (upower) to
implement audio routing/encoding/decoding or audio daemon (power supply)
to force implementing battery related operations.


For handle this problem I would like to propose a new way how to use and
implement HSP and HFP profiles on Linux.

Implement a new HSP/HFP daemon (I called it hsphfpd) which register HSP
and HFP profiles in bluez and then exports functionality for all other
specific applications via DBus API (API for audio, power supply, input
layer, telephony functions, vendor extensions, etc...). So it would acts
as proxy daemon between bluez and target applications (pulseaudio,
upower, ofono, ...)

This would simplify whole HFP usage as applications would not need to
re-implement parsing and processing of AT commands and it would allow
more applications to use HFP profile at one time. And also it means that
audio software does not have to implement telephony stack or power
supply operations.


I wrote a document how such DBus API could look like, see here:

  https://github.com/pali/hsphfpd-prototype/raw/prototype/hsphfpd.txt


And also I implemented "prototype" implementation to verify that
designed API make sense and can be really implemented. Prototype fully
supports HSP profile in both HS and AG role, plus HFP profile in HF
role. This prototype implementation is available here:

  https://github.com/pali/hsphfpd-prototype

Some other details are written in README:

  https://github.com/pali/hsphfpd-prototype/raw/prototype/README


What do you think about it? Does it make sense to have such design?
Would you accept usage of such hsphfpd daemon, implemented according to
specification, on Linux desktop?

I would like to hear your opinion if I should continue with this hsphfpd
design, or not.


With this design and implementation of hsphfpd is possible to easily fix
pulseaudio issue about power supply properties:

  https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/722


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