+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@xxxxxxxxx
Attachment:
signature.asc
Description: PGP signature
