+Denis from ofono

ofono and pulseaudio are two main users of HFP profile on Linux...

On Sunday 01 December 2019 19:57:40 Pali Rohár wrote:
> 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