Proposal for a new API and usage of Bluetooth HSP and HFP profiles on Linux

Proposal for a new API and usage of Bluetooth HSP and HFP profiles on Linux

[Pali Rohár]

[-- Attachment #1: Type: text/plain, Size: 3811 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Tanu Kaskinen]

On Sun, 2019-12-01 at 19:57 +0100, 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

I quite like this proposal. Avoiding the need to implement the button
press, battery level etc. handling separately in PulseAudio, oFono and
PipeWire seems like a pretty good justification to me. I assume you're
volunteering to maintain this new daemon?

It's not clear to me how this would affect the PulseAudio <-> oFono
interaction, if at all. When oFono is used, would PulseAudio get the
audio socket from oFono or hsphfpd? What about volume commands, would
they go through oFono or would PulseAudio interact with hsphfpd
directly?

I think hsphfpd should be part of bluetoothd, but if that's not
possible, then that's not possible.

(I don't want to get into a lengthy discussion about programming
languages, but I'll just note here that I don't like Perl.)

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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

[Pali Rohár]

[-- Attachment #1: Type: text/plain, Size: 6277 bytes --]

On Monday 02 December 2019 19:01:11 Tanu Kaskinen wrote:
> On Sun, 2019-12-01 at 19:57 +0100, 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
> 
> I quite like this proposal. Avoiding the need to implement the button
> press, battery level etc. handling separately in PulseAudio, oFono and
> PipeWire seems like a pretty good justification to me. I assume you're
> volunteering to maintain this new daemon?

Yes, I can maintain this new daemon.

> It's not clear to me how this would affect the PulseAudio <-> oFono
> interaction, if at all.

Only one application can register to bluez and "own" bluez socket for
communication with bluetooth headset. Currently it can be either
pulseaudio (with native backend in pulseaudio for HSP profile) or ofono
(with ofono backend in pulseaudio for HFP profile).

So if hsphfpd would be in use, then ofono would not be able to get
socket from bluez. And it would be needed to add a new "plugin" into
ofono to use hsphpfd for telephony operations. See hsphfpd.txt file
(there is diagram of usage).

> When oFono is used, would PulseAudio get the
> audio socket from oFono or hsphfpd?

Always from hsphfpd.

> What about volume commands, would they go through oFono or would
> PulseAudio interact with hsphfpd directly?

Internally they are handled by hsphpfd directly and appropriate API is
exported via DBus for audio application daemon (pulseaudio). For details
see hsphfpd.txt file, interface org.hsphfpd.AudioTransport.

> I think hsphfpd should be part of bluetoothd, but if that's not
> possible, then that's not possible.

I do not know if bluez developers are interested in having this code as
part of bluez project, specially when in bluez4 HFP profile was there
and in bluez5 was HFP code completely removed.

But it should not matter where hsphpfd is implemented.

> (I don't want to get into a lengthy discussion about programming
> languages, but I'll just note here that I don't like Perl.)

It is just a prototype. I used Perl just because it is faster for me to
implement parsing of AT commands needed for prototype purposes.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Proposal for a new API and usage of Bluetooth HSP and HFP profiles on Linux

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 819 bytes --]

Hi,

On Sun, Dec 01, 2019 at 07:57:40PM +0100, Pali Rohár wrote:
> [...]
>
> 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, ...)
>
> [...]

Makes sense to me. My TODO list for the power-supply subsystem
contains providing an API similar to uinput, but for batteries/chargers.
I suppose that would be very useful for the daemon :)

-- Sebastian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Arun Raghavan]

+Wim and George from PipeWire

On Tue, 3 Dec 2019, at 12:15 AM, Pali Rohár wrote:
> On Monday 02 December 2019 19:01:11 Tanu Kaskinen wrote:
> > On Sun, 2019-12-01 at 19:57 +0100, 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
> > 
> > I quite like this proposal. Avoiding the need to implement the button
> > press, battery level etc. handling separately in PulseAudio, oFono and
> > PipeWire seems like a pretty good justification to me. I assume you're
> > volunteering to maintain this new daemon?
> 
> Yes, I can maintain this new daemon.
> 
> > It's not clear to me how this would affect the PulseAudio <-> oFono
> > interaction, if at all.
> 
> Only one application can register to bluez and "own" bluez socket for
> communication with bluetooth headset. Currently it can be either
> pulseaudio (with native backend in pulseaudio for HSP profile) or ofono
> (with ofono backend in pulseaudio for HFP profile).
> 
> So if hsphfpd would be in use, then ofono would not be able to get
> socket from bluez. And it would be needed to add a new "plugin" into
> ofono to use hsphpfd for telephony operations. See hsphfpd.txt file
> (there is diagram of usage).
> 
> > When oFono is used, would PulseAudio get the
> > audio socket from oFono or hsphfpd?
> 
> Always from hsphfpd.
> 
> > What about volume commands, would they go through oFono or would
> > PulseAudio interact with hsphfpd directly?
> 
> Internally they are handled by hsphpfd directly and appropriate API is
> exported via DBus for audio application daemon (pulseaudio). For details
> see hsphfpd.txt file, interface org.hsphfpd.AudioTransport.
> 
> > I think hsphfpd should be part of bluetoothd, but if that's not
> > possible, then that's not possible.
> 
> I do not know if bluez developers are interested in having this code as
> part of bluez project, specially when in bluez4 HFP profile was there
> and in bluez5 was HFP code completely removed.
> 
> But it should not matter where hsphpfd is implemented.
> 
> > (I don't want to get into a lengthy discussion about programming
> > languages, but I'll just note here that I don't like Perl.)
> 
> It is just a prototype. I used Perl just because it is faster for me to
> implement parsing of AT commands needed for prototype purposes.

Broadly, I think this is a good thing to do. My main concern is having this be adequately maintained over a longer period of time.

The other thing to note is that in PipeWire, it is possible for external entities to implement the equivalent of a "sink" or "source" (it's just a node in PipeWire terminology), so in the long run, it might be good to have a single BT audio daemon that manages A2DP and HSP/HFP..

This would also have the benefit of moving codec dependencies out of PulseAudio (which I'll help mitigate in other ways within PulseAudio anyway).

Cheers,
Arun

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

[Pali Rohár]

[-- Attachment #1: Type: text/plain, Size: 2257 bytes --]

On Wednesday 04 December 2019 20:45:23 Arun Raghavan wrote:
> Broadly, I think this is a good thing to do. My main concern is having this be adequately maintained over a longer period of time.

I already prepared prototype implementation, so I know how hard is to
write or maintain this new daemon.

Are there any interested people in either implementing, maintaining or
in other way helping with this project?

The main problem in maintaining this HSP/HFP codebase I see that I do
not have enough testing devices. As we know lot of manufactures produce
devices which are not compliant to standards and this needs to be
handled in HSP/HFP codebase.

> The other thing to note is that in PipeWire, it is possible for external entities to implement the equivalent of a "sink" or "source" (it's just a node in PipeWire terminology), so in the long run, it might be good to have a single BT audio daemon that manages A2DP and HSP/HFP..

PipeWire or any other audio server (jack or bluez-alsa) can benefit from
this hsphfpd daemon that it does not have to implement (again) parsing
and interpreting AT commands (as needed for HFP standard).

For PipeWire developers: Do you have any special requirements for this
hsphfpd daemon which are needed for processing of audio?

See proposed DBus interface, specially "Audio Agent hierarchy":
https://github.com/pali/hsphfpd-prototype/raw/prototype/hsphfpd.txt

> This would also have the benefit of moving codec dependencies out of PulseAudio (which I'll help mitigate in other ways within PulseAudio anyway).

hsphfpd just prepares SCO audio socket and then via DBus pass it to
target application (pulseaudio, pipewire, jacks, ...). And it is up to
the audio application to do codec processing. hsphfpd is not going to do
anything with audio samples or codecs. So this does not help directly...

... But I'm planing to try to separate A2DP code from pulseaudio into
some external library which would not depend on pulseaudio. So this
library can help all audio server projects to not re-implement again and
again A2DP (and HSP/HFP) audio processing. This library should do all
needed codec stuff (encoding, decoding, setup of A2DP, ...).

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Pali Rohár]

On Monday 02 December 2019 19:45:12 Pali Rohár wrote:
> On Monday 02 December 2019 19:01:11 Tanu Kaskinen wrote:
> > I think hsphfpd should be part of bluetoothd, but if that's not
> > possible, then that's not possible.
> 
> I do not know if bluez developers are interested in having this code as
> part of bluez project, specially when in bluez4 HFP profile was there
> and in bluez5 was HFP code completely removed.

Hello, could someone from bluez developers comment this Tanu's point?

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

Re: Proposal for a new API and usage of Bluetooth HSP and HFP profiles on Linux

[Pali Rohár]

[-- Attachment #1: Type: text/plain, Size: 4148 bytes --]

+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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Proposal for a new API and usage of Bluetooth HSP and HFP profiles on Linux

[George Kiagiadakis]

+ the bluez-alsa maintainer

See my comments below...

On 07/12/2019 22:09, Pali Rohár wrote:

> +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
>>
>>

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

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

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

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)
* 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
* avoid the context switching overkill; we should only have 1 process
between bluez and the audio daemon / solution, imho
* 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)

I imagine that this component library would include:

* bluetooth audio codecs
* HFP/HSP commands handling
* telephony handling
* exposure of common D-Bus APIs for side-channel things like power
management or phone dialing

... 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

Re: 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@gmail.com

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

[Luiz Augusto von Dentz]

Hi Pali,

On Thu, Dec 5, 2019 at 11:32 AM Pali Rohár <pali.rohar@gmail.com> wrote:
>
> On Monday 02 December 2019 19:45:12 Pali Rohár wrote:
> > On Monday 02 December 2019 19:01:11 Tanu Kaskinen wrote:
> > > I think hsphfpd should be part of bluetoothd, but if that's not
> > > possible, then that's not possible.
> >
> > I do not know if bluez developers are interested in having this code as
> > part of bluez project, specially when in bluez4 HFP profile was there
> > and in bluez5 was HFP code completely removed.
>
> Hello, could someone from bluez developers comment this Tanu's point?

I would have to say no, we are definitely not interested in yet
another daemon for AT parsing, we actually have too many of these
around, either in a form of Modem Manager, oFono, etc. That said one
simpler way to resolve all of this is to maintain a plugin to
bluetoothd that way HSP/HFP becomes native again, that can either be
maintained in the tree or out of the tree.

-- 
Luiz Augusto von Dentz

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

[Pali Rohár]

Hi!

On Monday 16 December 2019 00:11:04 Luiz Augusto von Dentz wrote:
> Hi Pali,
> 
> On Thu, Dec 5, 2019 at 11:32 AM Pali Rohár <pali.rohar@gmail.com> wrote:
> >
> > On Monday 02 December 2019 19:45:12 Pali Rohár wrote:
> > > On Monday 02 December 2019 19:01:11 Tanu Kaskinen wrote:
> > > > I think hsphfpd should be part of bluetoothd, but if that's not
> > > > possible, then that's not possible.
> > >
> > > I do not know if bluez developers are interested in having this code as
> > > part of bluez project, specially when in bluez4 HFP profile was there
> > > and in bluez5 was HFP code completely removed.
> >
> > Hello, could someone from bluez developers comment this Tanu's point?
> 
> I would have to say no, we are definitely not interested in yet
> another daemon for AT parsing, we actually have too many of these
> around, either in a form of Modem Manager, oFono, etc.

Proposed hsphfpd daemon is not (only) for parsing AT commands, but for
implementing logic around HSP and HFP profiles and export either native
interfaces (linux uinput) or DBus interfaces for features provided by
HSP and HFP specifications and also for current and future vendor
extensions. And part of this HSP/HFP implementation is of course needed
parsing and interpreting some of AT commands. Look into my design and
API proposal. Current daemons which provides AT parsing (like ofono or
modem manager) are not suitable for for whole HSP and HFP profiles with
all those extensions (like all possible ways for reporting battery
level), so for HFP is needed some of custom AT parser.

> That said one
> simpler way to resolve all of this is to maintain a plugin to
> bluetoothd that way HSP/HFP becomes native again, that can either be
> maintained in the tree or out of the tree.

I do not see how could just plain plugin for bluez without AT parser
could help. This seems to just complicate whole implementation. I
already implemented prototype implementation of hsphfpd to see how
complicated it is and what is needed...

So if bluez daemon is not the right place for hsphpfd, it would be
separate daemon outside of bluez.

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

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

[Luiz Augusto von Dentz]

Hi Pali,

On Mon, Dec 16, 2019 at 1:15 AM Pali Rohár <pali.rohar@gmail.com> wrote:
>
> Hi!
>
> On Monday 16 December 2019 00:11:04 Luiz Augusto von Dentz wrote:
> > Hi Pali,
> >
> > On Thu, Dec 5, 2019 at 11:32 AM Pali Rohár <pali.rohar@gmail.com> wrote:
> > >
> > > On Monday 02 December 2019 19:45:12 Pali Rohár wrote:
> > > > On Monday 02 December 2019 19:01:11 Tanu Kaskinen wrote:
> > > > > I think hsphfpd should be part of bluetoothd, but if that's not
> > > > > possible, then that's not possible.
> > > >
> > > > I do not know if bluez developers are interested in having this code as
> > > > part of bluez project, specially when in bluez4 HFP profile was there
> > > > and in bluez5 was HFP code completely removed.
> > >
> > > Hello, could someone from bluez developers comment this Tanu's point?
> >
> > I would have to say no, we are definitely not interested in yet
> > another daemon for AT parsing, we actually have too many of these
> > around, either in a form of Modem Manager, oFono, etc.
>
> Proposed hsphfpd daemon is not (only) for parsing AT commands, but for
> implementing logic around HSP and HFP profiles and export either native
> interfaces (linux uinput) or DBus interfaces for features provided by
> HSP and HFP specifications and also for current and future vendor
> extensions. And part of this HSP/HFP implementation is of course needed
> parsing and interpreting some of AT commands. Look into my design and
> API proposal. Current daemons which provides AT parsing (like ofono or
> modem manager) are not suitable for for whole HSP and HFP profiles with
> all those extensions (like all possible ways for reporting battery
> level), so for HFP is needed some of custom AT parser.

Not following you on this one, oFono is intended for telephony
functionality and afaik it could parse battery, etc. Also would your
daemon include such functionality or you are to combine that with
oFono? I do appreciate the effort you have put into the SBC modes and
codec support but Im afraid you are going to experience some real pain
to maintain such a system all in your own, there are a lot of features
being exposed via AT commands and we risk to have yet another daemon
that just do parts of them until the next person comes with a
different use case and we are back to square one.

> > That said one
> > simpler way to resolve all of this is to maintain a plugin to
> > bluetoothd that way HSP/HFP becomes native again, that can either be
> > maintained in the tree or out of the tree.
>
> I do not see how could just plain plugin for bluez without AT parser
> could help. This seems to just complicate whole implementation. I
> already implemented prototype implementation of hsphfpd to see how
> complicated it is and what is needed...

Well the exactly the same thing with yet another daemon, we obviously
will need an AT parser, but the nice thing of being a native plugin is
that it can detect if another entity register for HSP/HFP and disable
itself (or have a policy to control that), the implementation can be
exactly what you have but without the extra rounds trips involved to
communicate back and forth with your daemon, so it is pretty straight
forward in terms o implementation.

> So if bluez daemon is not the right place for hsphpfd, it would be
> separate daemon outside of bluez.
>
> --
> Pali Rohár
> pali.rohar@gmail.com



-- 
Luiz Augusto von Dentz

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

[Pali Rohár]

[-- Attachment #1: Type: text/plain, Size: 5292 bytes --]

On Tuesday 17 December 2019 15:47:16 Luiz Augusto von Dentz wrote:
> Hi Pali,
> 
> On Mon, Dec 16, 2019 at 1:15 AM Pali Rohár <pali.rohar@gmail.com> wrote:
> >
> > Hi!
> >
> > On Monday 16 December 2019 00:11:04 Luiz Augusto von Dentz wrote:
> > > Hi Pali,
> > >
> > > On Thu, Dec 5, 2019 at 11:32 AM Pali Rohár <pali.rohar@gmail.com> wrote:
> > > >
> > > > On Monday 02 December 2019 19:45:12 Pali Rohár wrote:
> > > > > On Monday 02 December 2019 19:01:11 Tanu Kaskinen wrote:
> > > > > > I think hsphfpd should be part of bluetoothd, but if that's not
> > > > > > possible, then that's not possible.
> > > > >
> > > > > I do not know if bluez developers are interested in having this code as
> > > > > part of bluez project, specially when in bluez4 HFP profile was there
> > > > > and in bluez5 was HFP code completely removed.
> > > >
> > > > Hello, could someone from bluez developers comment this Tanu's point?
> > >
> > > I would have to say no, we are definitely not interested in yet
> > > another daemon for AT parsing, we actually have too many of these
> > > around, either in a form of Modem Manager, oFono, etc.
> >
> > Proposed hsphfpd daemon is not (only) for parsing AT commands, but for
> > implementing logic around HSP and HFP profiles and export either native
> > interfaces (linux uinput) or DBus interfaces for features provided by
> > HSP and HFP specifications and also for current and future vendor
> > extensions. And part of this HSP/HFP implementation is of course needed
> > parsing and interpreting some of AT commands. Look into my design and
> > API proposal. Current daemons which provides AT parsing (like ofono or
> > modem manager) are not suitable for for whole HSP and HFP profiles with
> > all those extensions (like all possible ways for reporting battery
> > level), so for HFP is needed some of custom AT parser.
> 
> Not following you on this one, oFono is intended for telephony
> functionality

and it should still be for telephony functionality.

> and afaik it could parse battery, etc. Also would your
> daemon include such functionality or you are to combine that with
> oFono?

Have you looked at my proposed API and design document? If not, please
really look at it... I already sent links in first email, but here are:

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

And if it is not clean how API works or how Agent should behave or how
whole ecosystem should work, please let me know which parts are not
clean so I can update it or explain even more.

All telephony AT commands (more specially, those which are not HFP
specific or which should not be handled by hsphfpd itself) are forwarded
to Telephony Agent. Ofono should be that Telephony Agent for hsphfpd for
handling all telephony stuff.

My hsphfpd daemon does not handle telephony functionality (except just
few commands which are required for HFP to work, but hsphfpd handles it
only when Telephony Agent is not connected).

> I do appreciate the effort you have put into the SBC modes and
> codec support but Im afraid you are going to experience some real pain
> to maintain such a system all in your own, there are a lot of features
> being exposed via AT commands and we risk to have yet another daemon
> that just do parts

Intension of hsphfpd is to dead with all these problems. For all new
functionality which would be introduced in future by vendors, hsphfpd
should be easily extended to either directly support this functionality
or to expose DBus API (or DBus file descriptor with AT socket) for
external application which would handle it.

> of them until the next person comes with a
> different use case and we are back to square one.
> 
> > > That said one
> > > simpler way to resolve all of this is to maintain a plugin to
> > > bluetoothd that way HSP/HFP becomes native again, that can either be
> > > maintained in the tree or out of the tree.
> >
> > I do not see how could just plain plugin for bluez without AT parser
> > could help. This seems to just complicate whole implementation. I
> > already implemented prototype implementation of hsphfpd to see how
> > complicated it is and what is needed...
> 
> Well the exactly the same thing with yet another daemon, we obviously
> will need an AT parser,

Yes, some AT parser would be still needed...

> but the nice thing of being a native plugin is
> that it can detect if another entity register for HSP/HFP and disable
> itself (or have a policy to control that), the implementation can be
> exactly what you have but without the extra rounds trips involved to
> communicate back and forth with your daemon, so it is pretty straight
> forward in terms o implementation.

I'm not sure if I understand it correctly, but does it mean to include
whole hsphfpd functionality into "bluez plugin" and bluetooth daemon
would then run this plugin, instead having hsphfpd in separate process?

> > So if bluez daemon is not the right place for hsphpfd, it would be
> > separate daemon outside of bluez.
> >
> > --
> > Pali Rohár
> > pali.rohar@gmail.com
> 
> 
> 

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Denis Kenzior]

Hi Pali,

On 12/16/19 3:15 AM, Pali Rohár wrote:
> Hi!
> 
> On Monday 16 December 2019 00:11:04 Luiz Augusto von Dentz wrote:
>> Hi Pali,
>>
>> On Thu, Dec 5, 2019 at 11:32 AM Pali Rohár <pali.rohar@gmail.com> wrote:
>>>
>>> On Monday 02 December 2019 19:45:12 Pali Rohár wrote:
>>>> On Monday 02 December 2019 19:01:11 Tanu Kaskinen wrote:
>>>>> I think hsphfpd should be part of bluetoothd, but if that's not
>>>>> possible, then that's not possible.
>>>>
>>>> I do not know if bluez developers are interested in having this code as
>>>> part of bluez project, specially when in bluez4 HFP profile was there
>>>> and in bluez5 was HFP code completely removed.
>>>
>>> Hello, could someone from bluez developers comment this Tanu's point?
>>
>> I would have to say no, we are definitely not interested in yet
>> another daemon for AT parsing, we actually have too many of these
>> around, either in a form of Modem Manager, oFono, etc.
> 
> Proposed hsphfpd daemon is not (only) for parsing AT commands, but for
> implementing logic around HSP and HFP profiles and export either native
> interfaces (linux uinput) or DBus interfaces for features provided by
> HSP and HFP specifications and also for current and future vendor
> extensions. And part of this HSP/HFP implementation is of course needed
> parsing and interpreting some of AT commands. Look into my design and
> API proposal. Current daemons which provides AT parsing (like ofono or
> modem manager) are not suitable for for whole HSP and HFP profiles with
> all those extensions (like all possible ways for reporting battery
> level), so for HFP is needed some of custom AT parser.

I'm not sure what logic around HSP you really care about.  It is just a 
single button press in the end.

For HFP, oFono can already support all sorts of extensions.  See for 
example how we handled Siri for HFP support in oFono here:
https://git.kernel.org/pub/scm/network/ofono/ofono.git/tree/doc/siri-api.txt. 
  Many of the extensions you talked about are also relevant for real 
modems as well (like battery reporting, call volume, etc).  Some of 
these APIs are already defined in fact.

Given the above, oFono upstream has no interest in adding or maintaining 
support this new framework.

Regards,
-Denis

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

[Pali Rohár]

[-- Attachment #1: Type: text/plain, Size: 3564 bytes --]

On Wednesday 18 December 2019 11:00:07 Denis Kenzior wrote:
> Hi Pali,
> 
> On 12/16/19 3:15 AM, Pali Rohár wrote:
> > Hi!
> > 
> > On Monday 16 December 2019 00:11:04 Luiz Augusto von Dentz wrote:
> > > Hi Pali,
> > > 
> > > On Thu, Dec 5, 2019 at 11:32 AM Pali Rohár <pali.rohar@gmail.com> wrote:
> > > > 
> > > > On Monday 02 December 2019 19:45:12 Pali Rohár wrote:
> > > > > On Monday 02 December 2019 19:01:11 Tanu Kaskinen wrote:
> > > > > > I think hsphfpd should be part of bluetoothd, but if that's not
> > > > > > possible, then that's not possible.
> > > > > 
> > > > > I do not know if bluez developers are interested in having this code as
> > > > > part of bluez project, specially when in bluez4 HFP profile was there
> > > > > and in bluez5 was HFP code completely removed.
> > > > 
> > > > Hello, could someone from bluez developers comment this Tanu's point?
> > > 
> > > I would have to say no, we are definitely not interested in yet
> > > another daemon for AT parsing, we actually have too many of these
> > > around, either in a form of Modem Manager, oFono, etc.
> > 
> > Proposed hsphfpd daemon is not (only) for parsing AT commands, but for
> > implementing logic around HSP and HFP profiles and export either native
> > interfaces (linux uinput) or DBus interfaces for features provided by
> > HSP and HFP specifications and also for current and future vendor
> > extensions. And part of this HSP/HFP implementation is of course needed
> > parsing and interpreting some of AT commands. Look into my design and
> > API proposal. Current daemons which provides AT parsing (like ofono or
> > modem manager) are not suitable for for whole HSP and HFP profiles with
> > all those extensions (like all possible ways for reporting battery
> > level), so for HFP is needed some of custom AT parser.
> 
> I'm not sure what logic around HSP you really care about.  It is just a
> single button press in the end.

CSR features (battery status level, ...) and CSR codec selection (e.g.
AuriStream). Also some apple extensions are used in HSP profile.

> For HFP, oFono can already support all sorts of extensions.  See for example
> how we handled Siri for HFP support in oFono here:
> https://git.kernel.org/pub/scm/network/ofono/ofono.git/tree/doc/siri-api.txt.

I saw. But it does not support usage of vendor codecs, like CSR
AuriStream and it does not support CSR extensions, like displaying text
on embedded display.

> Many of the extensions you talked about are also relevant for real modems as
> well (like battery reporting, call volume, etc).  Some of these APIs are
> already defined in fact.
> 
> Given the above, oFono upstream has no interest in adding or maintaining
> support this new framework.

Denis, if you are not interested in my proposed hsphfpd daemon, how you
want to solve problem with other extensions and other vendor codecs?

Also in my proposed solution it is possible to use HFP profile without
Telephony Agent (ofono). Do you think it is really a good idea to have
strong dependency on ofono just for bluetooth HFP headset?

Also for using ofono with HFP profile is not possible on desktop
computer which do not have any modem as it is hooked to some active
modem.

There is a way to use ofono sim simulator which provide fake modem, but
its setup is hard on desktop and it not automated.

So connecting bluetooth headset in HFP profile with ofono is something
not so easy and not an obvious way.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Pali Rohár]

[-- Attachment #1: Type: text/plain, Size: 4057 bytes --]

On Wednesday 18 December 2019 18:28:28 Pali Rohár wrote:
> On Wednesday 18 December 2019 11:00:07 Denis Kenzior wrote:
> > Hi Pali,
> > 
> > On 12/16/19 3:15 AM, Pali Rohár wrote:
> > > Hi!
> > > 
> > > On Monday 16 December 2019 00:11:04 Luiz Augusto von Dentz wrote:
> > > > Hi Pali,
> > > > 
> > > > On Thu, Dec 5, 2019 at 11:32 AM Pali Rohár <pali.rohar@gmail.com> wrote:
> > > > > 
> > > > > On Monday 02 December 2019 19:45:12 Pali Rohár wrote:
> > > > > > On Monday 02 December 2019 19:01:11 Tanu Kaskinen wrote:
> > > > > > > I think hsphfpd should be part of bluetoothd, but if that's not
> > > > > > > possible, then that's not possible.
> > > > > > 
> > > > > > I do not know if bluez developers are interested in having this code as
> > > > > > part of bluez project, specially when in bluez4 HFP profile was there
> > > > > > and in bluez5 was HFP code completely removed.
> > > > > 
> > > > > Hello, could someone from bluez developers comment this Tanu's point?
> > > > 
> > > > I would have to say no, we are definitely not interested in yet
> > > > another daemon for AT parsing, we actually have too many of these
> > > > around, either in a form of Modem Manager, oFono, etc.
> > > 
> > > Proposed hsphfpd daemon is not (only) for parsing AT commands, but for
> > > implementing logic around HSP and HFP profiles and export either native
> > > interfaces (linux uinput) or DBus interfaces for features provided by
> > > HSP and HFP specifications and also for current and future vendor
> > > extensions. And part of this HSP/HFP implementation is of course needed
> > > parsing and interpreting some of AT commands. Look into my design and
> > > API proposal. Current daemons which provides AT parsing (like ofono or
> > > modem manager) are not suitable for for whole HSP and HFP profiles with
> > > all those extensions (like all possible ways for reporting battery
> > > level), so for HFP is needed some of custom AT parser.
> > 
> > I'm not sure what logic around HSP you really care about.  It is just a
> > single button press in the end.
> 
> CSR features (battery status level, ...) and CSR codec selection (e.g.
> AuriStream). Also some apple extensions are used in HSP profile.
> 
> > For HFP, oFono can already support all sorts of extensions.  See for example
> > how we handled Siri for HFP support in oFono here:
> > https://git.kernel.org/pub/scm/network/ofono/ofono.git/tree/doc/siri-api.txt.

About Siri: In hsphfpd API it is delegated to Telephony Agent. So
hsphfpd is not going to (re)implement it.

> I saw. But it does not support usage of vendor codecs, like CSR
> AuriStream and it does not support CSR extensions, like displaying text
> on embedded display.
> 
> > Many of the extensions you talked about are also relevant for real modems as
> > well (like battery reporting, call volume, etc).  Some of these APIs are
> > already defined in fact.
> > 
> > Given the above, oFono upstream has no interest in adding or maintaining
> > support this new framework.

Maybe better question: Do you mean that you do not want to maintain
hsphfpd, or that you completely do not want to see that ofono would be
"Telepony Agent" for hsphfpd?

> Denis, if you are not interested in my proposed hsphfpd daemon, how you
> want to solve problem with other extensions and other vendor codecs?
> 
> Also in my proposed solution it is possible to use HFP profile without
> Telephony Agent (ofono). Do you think it is really a good idea to have
> strong dependency on ofono just for bluetooth HFP headset?
> 
> Also for using ofono with HFP profile is not possible on desktop
> computer which do not have any modem as it is hooked to some active
> modem.
> 
> There is a way to use ofono sim simulator which provide fake modem, but
> its setup is hard on desktop and it not automated.
> 
> So connecting bluetooth headset in HFP profile with ofono is something
> not so easy and not an obvious way.
> 

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Denis Kenzior]

Hi Pali,

>>> I'm not sure what logic around HSP you really care about.  It is just a
>>> single button press in the end.
>>
>> CSR features (battery status level, ...) and CSR codec selection (e.g.
>> AuriStream). Also some apple extensions are used in HSP profile.

Since HFP can do everything that HSP can and more, I view HSP as 
deprecated and not to be used.  If these are also available in HFP, then 
I'd just use HFP instead.  But HSP was never my focus, so if you feel 
there's a need for better HSP support, then fair enough.

>>
>>> For HFP, oFono can already support all sorts of extensions.  See for example
>>> how we handled Siri for HFP support in oFono here:
>>> https://git.kernel.org/pub/scm/network/ofono/ofono.git/tree/doc/siri-api.txt.
> 
> About Siri: In hsphfpd API it is delegated to Telephony Agent. So
> hsphfpd is not going to (re)implement it.
> 
>> I saw. But it does not support usage of vendor codecs, like CSR
>> AuriStream and it does not support CSR extensions, like displaying text
>> on embedded display.

But that's my point, you can easily accomplish this by creating another 
oFono API / atom for HFP CSR extensions and expose this information / 
functionality.  Similar to how Siri was done.  I see no need for a 
completely new external daemon.

>>
>>> Many of the extensions you talked about are also relevant for real modems as
>>> well (like battery reporting, call volume, etc).  Some of these APIs are
>>> already defined in fact.
>>>
>>> Given the above, oFono upstream has no interest in adding or maintaining
>>> support this new framework.
> 
> Maybe better question: Do you mean that you do not want to maintain
> hsphfpd, or that you completely do not want to see that ofono would be
> "Telepony Agent" for hsphfpd?

The latter.

> 
>> Denis, if you are not interested in my proposed hsphfpd daemon, how you
>> want to solve problem with other extensions and other vendor codecs?
>>

See above..

>> Also in my proposed solution it is possible to use HFP profile without
>> Telephony Agent (ofono). Do you think it is really a good idea to have
>> strong dependency on ofono just for bluetooth HFP headset?
>>

Why not?  The main purpose of HFP is telephony; whether it is classic 
phone calls or skype/facetime.  oFono seems a natural fit.

>> Also for using ofono with HFP profile is not possible on desktop
>> computer which do not have any modem as it is hooked to some active
>> modem.

This statement is not true at all.  You can use oFono without any 'real' 
modems attached.  It can happily manage only HFP devices (or modems as 
we call them.)

>>
>> There is a way to use ofono sim simulator which provide fake modem, but
>> its setup is hard on desktop and it not automated.
>>

You must be thinking of the oFono HFP AG implementation...

>> So connecting bluetooth headset in HFP profile with ofono is something
>> not so easy and not an obvious way.
>>

Again, not true.  As I said above, you can use oFono for this use case 
just fine.  Certainly the main driver for the development of oFono was 
to drive real modem hardware, but it isn't limited to that.  So if you 
want to use it only for HFP, you can.

Regards,
-Denis

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

[Pali Rohár]

[-- Attachment #1: Type: text/plain, Size: 5824 bytes --]

Hello Denis!

On Wednesday 18 December 2019 14:53:24 Denis Kenzior wrote:
> Hi Pali,
> 
> > > > I'm not sure what logic around HSP you really care about.  It is just a
> > > > single button press in the end.
> > > 
> > > CSR features (battery status level, ...) and CSR codec selection (e.g.
> > > AuriStream). Also some apple extensions are used in HSP profile.
> 
> Since HFP can do everything that HSP can and more, I view HSP as deprecated
> and not to be used.  If these are also available in HFP, then I'd just use
> HFP instead.  But HSP was never my focus, so if you feel there's a need for
> better HSP support, then fair enough.

Yes, I see. Also there are devices without HFP support, only with HSP.
pulseaudio support also these devices and pulseaudio is not going to
drop support for them. Last time when I looked at ofono, it has no HSP
support. Is ofono going to add support for HSP?

> > > 
> > > > For HFP, oFono can already support all sorts of extensions.  See for example
> > > > how we handled Siri for HFP support in oFono here:
> > > > https://git.kernel.org/pub/scm/network/ofono/ofono.git/tree/doc/siri-api.txt.
> > 
> > About Siri: In hsphfpd API it is delegated to Telephony Agent. So
> > hsphfpd is not going to (re)implement it.
> > 
> > > I saw. But it does not support usage of vendor codecs, like CSR
> > > AuriStream and it does not support CSR extensions, like displaying text
> > > on embedded display.
> 
> But that's my point, you can easily accomplish this by creating another
> oFono API / atom for HFP CSR extensions and expose this information /
> functionality.  Similar to how Siri was done.  I see no need for a
> completely new external daemon.

Ok. I agree that functionality from my hsphfpd prototype can be "moved"
to ofono.

But would you accept patches which exports DBus API e.g. for displaying text
on HFP headset with embedded display? Or patches which implements 3
different way for reporting battery level status of HFP headset? And API
for sending "computer battery level" to HFP headset? Or implementing
setup of SCO sockets (via RFCOMM layer) for custom codecs? Or exporting
uinput linux device for button press events? Because all these
functionalities looks like not relevant to telephony / modem stack and
for me it seems that ofono is not target application which should be
interested in implementing it.

> > > 
> > > > Many of the extensions you talked about are also relevant for real modems as
> > > > well (like battery reporting, call volume, etc).  Some of these APIs are
> > > > already defined in fact.
> > > > 
> > > > Given the above, oFono upstream has no interest in adding or maintaining
> > > > support this new framework.
> > 
> > Maybe better question: Do you mean that you do not want to maintain
> > hsphfpd, or that you completely do not want to see that ofono would be
> > "Telepony Agent" for hsphfpd?
> 
> The latter.

Ok.

> > 
> > > Denis, if you are not interested in my proposed hsphfpd daemon, how you
> > > want to solve problem with other extensions and other vendor codecs?
> > > 
> 
> See above..
> 
> > > Also in my proposed solution it is possible to use HFP profile without
> > > Telephony Agent (ofono). Do you think it is really a good idea to have
> > > strong dependency on ofono just for bluetooth HFP headset?
> > > 
> 
> Why not?  The main purpose of HFP is telephony; whether it is classic phone
> calls or skype/facetime.  oFono seems a natural fit.

I disagree here. Primary purpose of HFP for desktop users is ability to
use bluetooth's microphone. And not telephony stack and its complicated
features like call hold and others, which are in HFP used and
implemented probably only in car kits.

> > > Also for using ofono with HFP profile is not possible on desktop
> > > computer which do not have any modem as it is hooked to some active
> > > modem.
> 
> This statement is not true at all.  You can use oFono without any 'real'
> modems attached.  It can happily manage only HFP devices (or modems as we
> call them.)

Ok, can you please provide exact steps how to do it, including
activating of bidirectional audio stream?

Because from all information which I got, and also from talk with other
people, I think it really is not possible.

Also official pulseaudio documentation mention that you need phone sim
simulator for this purpose, see:

https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Bluetooth/#index5h2

> > > 
> > > There is a way to use ofono sim simulator which provide fake modem, but
> > > its setup is hard on desktop and it not automated.
> > > 
> 
> You must be thinking of the oFono HFP AG implementation...

Yes! For connecting bluetooth headset you need HFP AG implementation.

And I guess this is the reason why simulator is needed. HFP headset acts
as a "client" for modem. Therefore on desktop / laptop you need to
implement "modem server" which will be used by HFP headset "client".

And phone simulator is doing exactly this "modem server", it is
simulator of modem.

> > > So connecting bluetooth headset in HFP profile with ofono is something
> > > not so easy and not an obvious way.
> > > 
> 
> Again, not true.  As I said above, you can use oFono for this use case just
> fine.  Certainly the main driver for the development of oFono was to drive
> real modem hardware, but it isn't limited to that.  So if you want to use it
> only for HFP, you can.

If it is really possible (and need for phone simulator as described
above is not required) then there is completely missing documentation
how to do it. And how should be audio server (pulseaudio) configured to
work in this way.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Denis Kenzior]

Hi Pali,

> Yes, I see. Also there are devices without HFP support, only with HSP.
> pulseaudio support also these devices and pulseaudio is not going to
> drop support for them. Last time when I looked at ofono, it has no HSP
> support. Is ofono going to add support for HSP?
> 

No.

<snip>

> 
> But would you accept patches which exports DBus API e.g. for displaying text
> on HFP headset with embedded display? Or patches which implements 3
> different way for reporting battery level status of HFP headset? And API
> for sending "computer battery level" to HFP headset? Or implementing
> setup of SCO sockets (via RFCOMM layer) for custom codecs? Or exporting
> uinput linux device for button press events? Because all these

So which roles are we talking about here?  Your Design document shows 
hsphfpd registering for both HFP AG and HFP HF roles, but maybe this was 
not the intent?

If you're talking about extending oFono APIs when it is acting as the HF 
connecting to the AG, then codec setup APIs, etc are definitely 
something that would be welcome.

If you're talking about AG role, then that is different... In general, 
if the oFono is in an AG role, then there should be nothing to configure 
and there are no APIs for this role.  Things like reporting AG battery 
level to HFP headset are done directly using plugins.  See 
ofono_emulator_set_indicator and how this is done by upower.c for 
example.  I happily take patches for any additional features (codecs, 
etc) you want to support here.

But... oFono upstream has no interest in accepting forwarded AT commands 
from some external daemon if we're in AG role.  We rejected such a 
design years ago and nothing has changed.

AG role is already quite tricky to implement without additional 
complexity introduced by having multiple applications and IPC.  "Its 
your funeral" as the saying goes if you want to go that route.

<snip>

> I disagree here. Primary purpose of HFP for desktop users is ability to
> use bluetooth's microphone. And not telephony stack and its complicated
> features like call hold and others, which are in HFP used and
> implemented probably only in car kits.

So your primary goal here is to have the desktop play the role of the 
AG, purely so you can forward the audio from a headset out to whatever 
it is that you want.  And you want oFono (or some other daemon) to 
(optionally) handle the call related AT commands in the HFP AG role.

Such a design will get a NAK from me on the oFono side.  But don't let 
that stop you.  You can simply invoke oFono APIs directly from your 
daemon.  No need for any changes in oFono itself.  As mentioned above, I 
wouldn't recommend it, but... :)

> 
>>>> Also for using ofono with HFP profile is not possible on desktop
>>>> computer which do not have any modem as it is hooked to some active
>>>> modem.
>>
>> This statement is not true at all.  You can use oFono without any 'real'
>> modems attached.  It can happily manage only HFP devices (or modems as we
>> call them.)
> 
> Ok, can you please provide exact steps how to do it, including
> activating of bidirectional audio stream?

So again, which role?  If we're the HF connecting to the AG, then things 
just work without a modem.  If we're the AG, then yes you need a modem 
to be driven by the AG connection.

>>
>> You must be thinking of the oFono HFP AG implementation...
> 
> Yes! For connecting bluetooth headset you need HFP AG implementation.
> 
> And I guess this is the reason why simulator is needed. HFP headset acts
> as a "client" for modem. Therefore on desktop / laptop you need to
> implement "modem server" which will be used by HFP headset "client".
> 
> And phone simulator is doing exactly this "modem server", it is
> simulator of modem.
> 

Okay, I see now.  Yes, the above is correct.  My comments about not 
needing a modem device hold true only if oFono is in HFP HF role 
connecting to an AG.

Regards,
-Denis

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

[Pali Rohár]

[-- Attachment #1: Type: text/plain, Size: 6300 bytes --]

Hi Denis!

On Wednesday 18 December 2019 19:03:12 Denis Kenzior wrote:
> Hi Pali,
> 
> > Yes, I see. Also there are devices without HFP support, only with HSP.
> > pulseaudio support also these devices and pulseaudio is not going to
> > drop support for them. Last time when I looked at ofono, it has no HSP
> > support. Is ofono going to add support for HSP?
> > 
> 
> No.

So your answer means that we cannot use ofono at all and therefore we
need another daemon (like my proposed hsphfpd).

> <snip>
> 
> > 
> > But would you accept patches which exports DBus API e.g. for displaying text
> > on HFP headset with embedded display? Or patches which implements 3
> > different way for reporting battery level status of HFP headset? And API
> > for sending "computer battery level" to HFP headset? Or implementing
> > setup of SCO sockets (via RFCOMM layer) for custom codecs? Or exporting
> > uinput linux device for button press events? Because all these
> 
> So which roles are we talking about here?  Your Design document shows
> hsphfpd registering for both HFP AG and HFP HF roles, but maybe this was not
> the intent?

My proposed hsphfpd is going to support both roles. Which means to
implement whole HFP profile. So for connecting bluetooth headsets (when
AG role is needed on desktop) and also for connecting mobile phones
(when HF role is needed on desktop).

And my primary motivation is for bluetooth headsets as this is what are
asking desktop and laptop users again and again that is missing on Linux
systems.

So higher priority has AG role and slightly lower priority has HF role.

> If you're talking about extending oFono APIs when it is acting as the HF
> connecting to the AG, then codec setup APIs, etc are definitely something
> that would be welcome.
> 
> If you're talking about AG role, then that is different... In general, if
> the oFono is in an AG role, then there should be nothing to configure and
> there are no APIs for this role.

Codecs needs to be configured also in AG role. Before accepting SCO
connection you need to configure SCO socket for correct codec. Also for
vendor codecs it needs to be properly negotiated via AT commands.

> Things like reporting AG battery level to
> HFP headset are done directly using plugins.  See
> ofono_emulator_set_indicator and how this is done by upower.c for example.
> I happily take patches for any additional features (codecs, etc) you want to
> support here.
> 
> But... oFono upstream has no interest in accepting forwarded AT commands
> from some external daemon if we're in AG role.  We rejected such a design
> years ago and nothing has changed.
> 
> AG role is already quite tricky to implement without additional complexity
> introduced by having multiple applications and IPC.  "Its your funeral" as
> the saying goes if you want to go that route.

I know that it is not so easy to implement --- I already created
prototype implementation and proposed API how to do it.

But 

> <snip>
> 
> > I disagree here. Primary purpose of HFP for desktop users is ability to
> > use bluetooth's microphone. And not telephony stack and its complicated
> > features like call hold and others, which are in HFP used and
> > implemented probably only in car kits.
> 
> So your primary goal here is to have the desktop play the role of the AG,
> purely so you can forward the audio from a headset out to whatever it is
> that you want.  And you want oFono (or some other daemon) to (optionally)
> handle the call related AT commands in the HFP AG role.

Yes. Exactly.

> Such a design will get a NAK from me on the oFono side.  But don't let that
> stop you.  You can simply invoke oFono APIs directly from your daemon.  No
> need for any changes in oFono itself.  As mentioned above, I wouldn't
> recommend it, but... :)

So if you are disagreeing with this design, can you propose alternative?
Which would support needs for desktop users? Support for HSP profile (in
AG role), support for HFP profile (in AG role), ability to parse and
interpret needed AT commands. And later also HS and HF role of these
profiles.

> > 
> > > > > Also for using ofono with HFP profile is not possible on desktop
> > > > > computer which do not have any modem as it is hooked to some active
> > > > > modem.
> > > 
> > > This statement is not true at all.  You can use oFono without any 'real'
> > > modems attached.  It can happily manage only HFP devices (or modems as we
> > > call them.)
> > 
> > Ok, can you please provide exact steps how to do it, including
> > activating of bidirectional audio stream?
> 
> So again, which role?  If we're the HF connecting to the AG, then things
> just work without a modem.  If we're the AG, then yes you need a modem to be
> driven by the AG connection.

AG.

> > > 
> > > You must be thinking of the oFono HFP AG implementation...
> > 
> > Yes! For connecting bluetooth headset you need HFP AG implementation.
> > 
> > And I guess this is the reason why simulator is needed. HFP headset acts
> > as a "client" for modem. Therefore on desktop / laptop you need to
> > implement "modem server" which will be used by HFP headset "client".
> > 
> > And phone simulator is doing exactly this "modem server", it is
> > simulator of modem.
> > 
> 
> Okay, I see now.  Yes, the above is correct.  My comments about not needing
> a modem device hold true only if oFono is in HFP HF role connecting to an
> AG.

Ok. So I guess now you understood main problem. I thought it was
obvious, but seems that bluetooth HFP is too complicated, so talking
about it always needs more detailed explanation. Sorry for that if it
was not clear from my side since beginning what are requirements for my
setup.

And question now is how to solve this problem for desktop computers?
Users who want to use their bluetooth headset (HF role on headset; AG
role on laptop) really do not want to do complicated setup of modem
simulator just to use microphone input from headset.

This is reason why I'm proposing hsphfpd daemon and with its API to work
without any modem emulator or ofono software (but optionally modem could
be connected).

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Denis Kenzior]

Hi Pali,

>>> But would you accept patches which exports DBus API e.g. for displaying text
>>> on HFP headset with embedded display? Or patches which implements 3
>>> different way for reporting battery level status of HFP headset? And API
>>> for sending "computer battery level" to HFP headset? Or implementing
>>> setup of SCO sockets (via RFCOMM layer) for custom codecs? Or exporting
>>> uinput linux device for button press events? Because all these
>>
>> So which roles are we talking about here?  Your Design document shows
>> hsphfpd registering for both HFP AG and HFP HF roles, but maybe this was not
>> the intent?
> 
> My proposed hsphfpd is going to support both roles. Which means to
> implement whole HFP profile. So for connecting bluetooth headsets (when
> AG role is needed on desktop) and also for connecting mobile phones
> (when HF role is needed on desktop).
> 
> And my primary motivation is for bluetooth headsets as this is what are
> asking desktop and laptop users again and again that is missing on Linux
> systems.
> 
> So higher priority has AG role and slightly lower priority has HF role.
> 

So to summarize.  You have broadly 3 main use cases for HFP:

1. HF connecting to AG role.  Essentially a carkit role.  oFono does 
this pretty well already and has the APIs defined that cover up to HFP 
1.7.  Any vendor extensions can be easily added.  And some carkit 
manufacturers already use it.

2. AG role when you have a 'real modem' behind it.  oFono already 
provides everything needed for this scenario.

3. AG role when you don't have a real modem or you have some sort of 
VoIP use case.  oFono doesn't cover this case as you stated.

So I can see value in something that implements case #3.  But having 
said that, oFono will not be receiving AT commands from external daemons:
	- For case 1, it'd just be a rehash of what oFono does well already.  I 
reinvented a few wheels in my time, but doesn't mean I think this one 
should be.
	- The reasoning for case 2/3 I already covered upthread.

>> If you're talking about extending oFono APIs when it is acting as the HF
>> connecting to the AG, then codec setup APIs, etc are definitely something
>> that would be welcome.
>>
>> If you're talking about AG role, then that is different... In general, if
>> the oFono is in an AG role, then there should be nothing to configure and
>> there are no APIs for this role.
> 
> Codecs needs to be configured also in AG role. Before accepting SCO
> connection you need to configure SCO socket for correct codec. Also for
> vendor codecs it needs to be properly negotiated via AT commands.
>

Sure, but that doesn't mean they need an actual D-Bus API to be 
configured with.  You can simply extend oFono emulator to support 
whatever codecs you want and whatever custom AT command handling that 
you need.  If the HF requests the codec, then you use it.  There's no 
D-Bus API required here.  Again, take a look at how this is done in 
oFono today.

>> Such a design will get a NAK from me on the oFono side.  But don't let that
>> stop you.  You can simply invoke oFono APIs directly from your daemon.  No
>> need for any changes in oFono itself.  As mentioned above, I wouldn't
>> recommend it, but... :)
> 
> So if you are disagreeing with this design, can you propose alternative?
> Which would support needs for desktop users? Support for HSP profile (in
> AG role), support for HFP profile (in AG role), ability to parse and
> interpret needed AT commands. And later also HS and HF role of these
> profiles.
> 

There have been one or two implementations of AG role fully external to 
oFono.  These implementations simply used the existing oFono APIs to 
drive the modem.  You could do that.  But as I said, we rejected such a 
design a long time ago due to complexity and other issues.

Or you can ignore the call control aspects entirely...

But in the end, it is your architecture.  All I can do is point out 
(early in the process) what is and what is not acceptable to oFono upstream.

>>
>> Okay, I see now.  Yes, the above is correct.  My comments about not needing
>> a modem device hold true only if oFono is in HFP HF role connecting to an
>> AG.
> 
> Ok. So I guess now you understood main problem. I thought it was
> obvious, but seems that bluetooth HFP is too complicated, so talking
> about it always needs more detailed explanation. Sorry for that if it
> was not clear from my side since beginning what are requirements for my
> setup.

Well it was a bit of reading comprehension fail on my part as well.  The 
two roles are really quite different, so precise language helps.

Regards,
-Denis

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

[Pali Rohár]

[-- Attachment #1: Type: text/plain, Size: 8101 bytes --]

Hi Denis!

On Thursday 19 December 2019 08:53:54 Denis Kenzior wrote:
> Hi Pali,
> 
> > > > But would you accept patches which exports DBus API e.g. for displaying text
> > > > on HFP headset with embedded display? Or patches which implements 3
> > > > different way for reporting battery level status of HFP headset? And API
> > > > for sending "computer battery level" to HFP headset? Or implementing
> > > > setup of SCO sockets (via RFCOMM layer) for custom codecs? Or exporting
> > > > uinput linux device for button press events? Because all these
> > > 
> > > So which roles are we talking about here?  Your Design document shows
> > > hsphfpd registering for both HFP AG and HFP HF roles, but maybe this was not
> > > the intent?
> > 
> > My proposed hsphfpd is going to support both roles. Which means to
> > implement whole HFP profile. So for connecting bluetooth headsets (when
> > AG role is needed on desktop) and also for connecting mobile phones
> > (when HF role is needed on desktop).
> > 
> > And my primary motivation is for bluetooth headsets as this is what are
> > asking desktop and laptop users again and again that is missing on Linux
> > systems.
> > 
> > So higher priority has AG role and slightly lower priority has HF role.
> > 
> 
> So to summarize.  You have broadly 3 main use cases for HFP:
> 
> 1. HF connecting to AG role.  Essentially a carkit role.  oFono does this
> pretty well already and has the APIs defined that cover up to HFP 1.7.  Any
> vendor extensions can be easily added.  And some carkit manufacturers
> already use it.
> 
> 2. AG role when you have a 'real modem' behind it.  oFono already provides
> everything needed for this scenario.
> 
> 3. AG role when you don't have a real modem or you have some sort of VoIP
> use case.  oFono doesn't cover this case as you stated.

In your list are missing another two use cases:

4. AG role without real modem connecting yo HS role in HSP profile

5. HS role connecting to AG role in HSP profile


3. and 4. is my primary focus which is the most common scenario for
desktop / laptop users with bluetooth headset. 5., 2. and 1. are also
covered in hsphfpd design, but with lower priority (implemented after 3.
and 4. is fully working).

3. and 4. would share some part of code, specially handling of battery
status parsing via CSR and Apple extensions or CSR codec selection.

What do you suggest for 4. and 5.?

> So I can see value in something that implements case #3.  But having said
> that, oFono will not be receiving AT commands from external daemons:
> 	- For case 1, it'd just be a rehash of what oFono does well already.  I
> reinvented a few wheels in my time, but doesn't mean I think this one should
> be.
> 	- The reasoning for case 2/3 I already covered upthread.
> 
> > > If you're talking about extending oFono APIs when it is acting as the HF
> > > connecting to the AG, then codec setup APIs, etc are definitely something
> > > that would be welcome.
> > > 
> > > If you're talking about AG role, then that is different... In general, if
> > > the oFono is in an AG role, then there should be nothing to configure and
> > > there are no APIs for this role.
> > 
> > Codecs needs to be configured also in AG role. Before accepting SCO
> > connection you need to configure SCO socket for correct codec. Also for
> > vendor codecs it needs to be properly negotiated via AT commands.
> > 
> 
> Sure, but that doesn't mean they need an actual D-Bus API to be configured
> with.  You can simply extend oFono emulator to support whatever codecs you
> want and whatever custom AT command handling that you need.  If the HF
> requests the codec, then you use it.  There's no D-Bus API required here.
> Again, take a look at how this is done in oFono today.
> 
> > > Such a design will get a NAK from me on the oFono side.  But don't let that
> > > stop you.  You can simply invoke oFono APIs directly from your daemon.  No
> > > need for any changes in oFono itself.  As mentioned above, I wouldn't
> > > recommend it, but... :)
> > 
> > So if you are disagreeing with this design, can you propose alternative?
> > Which would support needs for desktop users? Support for HSP profile (in
> > AG role), support for HFP profile (in AG role), ability to parse and
> > interpret needed AT commands. And later also HS and HF role of these
> > profiles.
> > 
> 
> There have been one or two implementations of AG role fully external to
> oFono.  These implementations simply used the existing oFono APIs to drive
> the modem.

bluez & pulseaudio developers told me that it would be a good idea to
avoid implementing a new AT parser for telephony stack. And rather use
ofono implementation for telephony part...

But if I should use existing DBus API provided by ofono, it means that I
need to do parsing of all AT commands (including telephony) and
translate them to ofono DBus API.

I agree, this should work and there is not need to modify ofono. But it
means that in hsphfpd daemon I need to have full AT parser for all
telephony commands and it was something which bluez / pa developers
thought that should be avoided. Therefore I come up with idea that
telephony commands would be handled by external Telephony Agent, which
can be ofono.

> You could do that.  But as I said, we rejected such a design a
> long time ago due to complexity and other issues.

Anyway, what is the problem with accepting modem socket in ofono via
DBus and starts talking with it like with any other modem which ofono
supports? Currently ofono already takes modem socket from bluez via DBus
API, so in same way hsphfpd can pass modem socket to ofono. Basically
ofono then can reuse same code which already uses for sockets from
bluez, just it do not have to parse and interpret audio related AT
commands (as these are handled by hsphpfd itself).

What are exact issues? I do not see complexity at ofono part (as has
already everything implemented) and currently I do not see those "other"
issues.

> Or you can ignore the call control aspects entirely...
> 
> But in the end, it is your architecture.  All I can do is point out (early
> in the process) what is and what is not acceptable to oFono upstream.

And this is why I started discussion across all projects (pulseaudio,
bluez, ofono) so describe current problem and come up with some
architecture which would be suitable for all projects. So thanks for all
your points.

You suggested to use phone simulator together with ofono and then
starts extending / patching phone simulator to supports all needed parts
which are in my hsphfpd design (battery status, button press, codec
selection)?

Also how to handle the main problem of phone simulator that it is too
much complicated to setup it on desktop? Looking at the steps...

https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Bluetooth/#index5h2

... that desktop user needs to run nontrivial commands in command like,
plus creating configuration file only just to connect bluetooth headset
is ridiculous and non-acceptable for desktop application.

If this problem is not fixed, ofono and phone simulator are not usable
as "main" software implementation of HFP profile for usage of bluetooth
headsets on Linux.

> > > 
> > > Okay, I see now.  Yes, the above is correct.  My comments about not needing
> > > a modem device hold true only if oFono is in HFP HF role connecting to an
> > > AG.
> > 
> > Ok. So I guess now you understood main problem. I thought it was
> > obvious, but seems that bluetooth HFP is too complicated, so talking
> > about it always needs more detailed explanation. Sorry for that if it
> > was not clear from my side since beginning what are requirements for my
> > setup.
> 
> Well it was a bit of reading comprehension fail on my part as well.  The two
> roles are really quite different, so precise language helps.
> 
> Regards,
> -Denis

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Denis Kenzior]

Hi Pali,

>> There have been one or two implementations of AG role fully external to
>> oFono.  These implementations simply used the existing oFono APIs to drive
>> the modem.
> 
> bluez & pulseaudio developers told me that it would be a good idea to
> avoid implementing a new AT parser for telephony stack. And rather use
> ofono implementation for telephony part...

In my opinion there's nothing scary about AT parsing.  In fact that is 
the easiest part of this whole venture.  If you don't want to roll your 
own parser, you can borrow one from the oFono project.  We already 
solved this nicely in the form of the gatchat library.  You could 
incorporate this into your project (if it is GPL compatible).  Or you 
could wait until we port gatchat to ell which will be under LGPL license.

> 
> But if I should use existing DBus API provided by ofono, it means that I
> need to do parsing of all AT commands (including telephony) and
> translate them to ofono DBus API.

I think you will need to do this regardless.  Otherwise I fail to see 
how you prevent one 'agent' from consuming AT commands it shouldn't be. 
This is a possibility you need to consider, whether it happens by 
accident or maliciously.

> 
> I agree, this should work and there is not need to modify ofono. But it
> means that in hsphfpd daemon I need to have full AT parser for all
> telephony commands and it was something which bluez / pa developers
> thought that should be avoided. Therefore I come up with idea that
> telephony commands would be handled by external Telephony Agent, which
> can be ofono.

Understood.  But I think the metric function was selected 
inappropriately in this case.  My opinion is that you should have 
started with what the overall architecture should look like; you should 
not have based design decisions on which parts might be a little hard to 
implement.

> 
>> You could do that.  But as I said, we rejected such a design a
>> long time ago due to complexity and other issues.
> 
> Anyway, what is the problem with accepting modem socket in ofono via
> DBus and starts talking with it like with any other modem which ofono
> supports? Currently ofono already takes modem socket from bluez via DBus
> API, so in same way hsphfpd can pass modem socket to ofono. Basically
> ofono then can reuse same code which already uses for sockets from
> bluez, just it do not have to parse and interpret audio related AT
> commands (as these are handled by hsphpfd itself).
> 
> What are exact issues? I do not see complexity at ofono part (as has
> already everything implemented) and currently I do not see those "other"
> issues.

The issues are many.  And really the question is not whether it 'could 
be' done, but whether it 'should be' done.  Let me describe a couple 
examples:

- In the case of HF role (1), oFono already provides all the necessary 
APIs.  So put yourself in oFono's maintainer shoes.  What would we gain 
by supporting almost the same but different mechanism?  We would have to 
introduce a new hfp_hf plugin, one that is almost identical, but 
different to hfp_hf_bluez5 plugin.  These two plugins would have 
coexistence issues, which would add more complexity.  Then there's the 
impact on PulseAudio and other users.  How do they know when to use the 
HandsfreeAudio API vs some external API?  Supporting this new way buys 
us a lot of extra code / complexity with no value added.

- The other example is more practical. HFP Service Level Connection 
(SLC) establishment is actually quite tricky.  There are certain 
limitations on what can and cannot be done prior to SLC establishment, 
including how audio handling is done.  Unfortunately, codec negotiation, 
indicator negotiation, and feature negotiation are part of the SLC. 
oFono already solves all of this and handles all of it nicely.  We have 
passed all relevant certification testing.  It is very unclear how you 
plan to handle this (or whether you realistically even can) in your 
architecture when the responsibilities are split between the various 
daemons.  So again, oFono has nothing to gain here...

> 
> You suggested to use phone simulator together with ofono and then
> starts extending / patching phone simulator to supports all needed parts
> which are in my hsphfpd design (battery status, button press, codec
> selection)?
> 

Not quite.  I suggested you expand oFono's emulator implementation (for 
AG role) and its DBus APIs (for HF role) to support the new vendor 
specific features that you want.

Forget about the phone simulator, it is really irrelevant for what 
you're trying to accomplish.

> Also how to handle the main problem of phone simulator that it is too
> much complicated to setup it on desktop? Looking at the steps...
> 
> https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Bluetooth/#index5h2
> 
> ... that desktop user needs to run nontrivial commands in command like,
> plus creating configuration file only just to connect bluetooth headset
> is ridiculous and non-acceptable for desktop application.
> 
> If this problem is not fixed, ofono and phone simulator are not usable
> as "main" software implementation of HFP profile for usage of bluetooth
> headsets on Linux.

oFono was never advertised as solving the 'HFP AG without a modem' use 
case.  This is something we never had as a requirement / objective. 
Phonesim is a development tool.  So of course it isn't trivial to setup, 
it isn't meant to be used in production in the first place.  The use of 
phonesim described in the PA wiki, while creative, is a giant hack ;)

Basically it all boils down to the fact that nobody has stepped up all 
this time to solve a particular use case you care about.  But blaming 
oFono for this is misguided.

So, if you want to solve the HFP AG without a modem case I fully support 
your efforts.

Perhaps this can even be solved in oFono itself (since it already does 
90% of what you want) by making the modem requirement optional.  What we 
could do for example is to create a dummy modem if an AG connection is 
requested and no other suitable modems are detected in the system.  The 
resultant AG wouldn't have any call control capability, it could still 
be used for transferring audio data, battery, etc.  If you want to 
pursue this, we can brainstorm further.

Regards,
-Denis

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

[Pali Rohár]

[-- Attachment #1: Type: text/plain, Size: 9771 bytes --]

Hi!

On Friday 20 December 2019 15:19:01 Denis Kenzior wrote:
> Hi Pali,
> 
> > > There have been one or two implementations of AG role fully external to
> > > oFono.  These implementations simply used the existing oFono APIs to drive
> > > the modem.
> > 
> > bluez & pulseaudio developers told me that it would be a good idea to
> > avoid implementing a new AT parser for telephony stack. And rather use
> > ofono implementation for telephony part...
> 
> In my opinion there's nothing scary about AT parsing.  In fact that is the
> easiest part of this whole venture.  If you don't want to roll your own
> parser, you can borrow one from the oFono project.  We already solved this
> nicely in the form of the gatchat library.  You could incorporate this into
> your project (if it is GPL compatible).  Or you could wait until we port
> gatchat to ell which will be under LGPL license.
> 
> > 
> > But if I should use existing DBus API provided by ofono, it means that I
> > need to do parsing of all AT commands (including telephony) and
> > translate them to ofono DBus API.
> 
> I think you will need to do this regardless.  Otherwise I fail to see how
> you prevent one 'agent' from consuming AT commands it shouldn't be. This is
> a possibility you need to consider, whether it happens by accident or
> maliciously.

Some subset of AT commands are needed to parse and interpret. But not
telephony commands and having up-to-date internal telephony state.

> > 
> > I agree, this should work and there is not need to modify ofono. But it
> > means that in hsphfpd daemon I need to have full AT parser for all
> > telephony commands and it was something which bluez / pa developers
> > thought that should be avoided. Therefore I come up with idea that
> > telephony commands would be handled by external Telephony Agent, which
> > can be ofono.
> 
> Understood.  But I think the metric function was selected inappropriately in
> this case.  My opinion is that you should have started with what the overall
> architecture should look like; you should not have based design decisions on
> which parts might be a little hard to implement.
> 
> > 
> > > You could do that.  But as I said, we rejected such a design a
> > > long time ago due to complexity and other issues.
> > 
> > Anyway, what is the problem with accepting modem socket in ofono via
> > DBus and starts talking with it like with any other modem which ofono
> > supports? Currently ofono already takes modem socket from bluez via DBus
> > API, so in same way hsphfpd can pass modem socket to ofono. Basically
> > ofono then can reuse same code which already uses for sockets from
> > bluez, just it do not have to parse and interpret audio related AT
> > commands (as these are handled by hsphpfd itself).
> > 
> > What are exact issues? I do not see complexity at ofono part (as has
> > already everything implemented) and currently I do not see those "other"
> > issues.
> 
> The issues are many.  And really the question is not whether it 'could be'
> done, but whether it 'should be' done.  Let me describe a couple examples:
> 
> - In the case of HF role (1), oFono already provides all the necessary APIs.
> So put yourself in oFono's maintainer shoes.  What would we gain by
> supporting almost the same but different mechanism?  We would have to
> introduce a new hfp_hf plugin, one that is almost identical, but different
> to hfp_hf_bluez5 plugin.

Yes, this would be needed, but because code os very similar it could be
reused from one common place.

> These two plugins would have coexistence issues,
> which would add more complexity.  Then there's the impact on PulseAudio and
> other users.  How do they know when to use the HandsfreeAudio API vs some
> external API?

Because pulseaudio has already own implementation of HSP profile and
some kind of ofono implementation (which you named below "giant hack")
it already needs to handle such problem.

But solution should be relatively simple. If we decide that new daemon
is "new proper way" then it would have higher priority as current HFP
API by ofono. So if hsphfpd is registered on dbus && hsphfpd say that it
is active, then use hsphfpd. Otherwise if ofono is registered on dbus
and say that device is active/connected use ofono.

> Supporting this new way buys us a lot of extra code /
> complexity with no value added.

Value is support for HSP profile and support for HFP AG role without
modem. And it would provide (for PA) unified same interface as for HFP
HF role and HFP AG role with modem. I think this is a big value for PA
(or bluez alsa or pipewire) to have one API which would handle all HSP
and HFP profile/role combinations.

> - The other example is more practical. HFP Service Level Connection (SLC)
> establishment is actually quite tricky.  There are certain limitations on
> what can and cannot be done prior to SLC establishment, including how audio
> handling is done.

I know :-) I already implemented prototype implementation to check and
see how complicated it is and if API make sense and how hard it is for
agents (audio - pulseaudio) implement and maintain it.

> Unfortunately, codec negotiation, indicator negotiation,
> and feature negotiation are part of the SLC. oFono already solves all of
> this and handles all of it nicely.

CSR codecs are not supported nor implemented in ofono. It is more
complicated as HFP codecs... and needs a new API for audio application.
Another value which brings my hsphfpd is that it handles these CSR
codecs and provide API for audio application to use them.

> We have passed all relevant
> certification testing.  It is very unclear how you plan to handle this (or
> whether you realistically even can) in your architecture when the
> responsibilities are split between the various daemons.  So again, oFono has
> nothing to gain here...

I was not thinking about certification. It is not something which I
could do.... And also pulseaudio itself do not have certifications.

> > 
> > You suggested to use phone simulator together with ofono and then
> > starts extending / patching phone simulator to supports all needed parts
> > which are in my hsphfpd design (battery status, button press, codec
> > selection)?
> > 
> 
> Not quite.  I suggested you expand oFono's emulator implementation (for AG
> role) and its DBus APIs (for HF role) to support the new vendor specific
> features that you want.
> 
> Forget about the phone simulator, it is really irrelevant for what you're
> trying to accomplish.

Ok. I thought that phone simulator = ofono emulator. I just saw that
phone simulator which is described in pulseaudio documentation.

> > Also how to handle the main problem of phone simulator that it is too
> > much complicated to setup it on desktop? Looking at the steps...
> > 
> > https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Bluetooth/#index5h2
> > 
> > ... that desktop user needs to run nontrivial commands in command like,
> > plus creating configuration file only just to connect bluetooth headset
> > is ridiculous and non-acceptable for desktop application.
> > 
> > If this problem is not fixed, ofono and phone simulator are not usable
> > as "main" software implementation of HFP profile for usage of bluetooth
> > headsets on Linux.
> 
> oFono was never advertised as solving the 'HFP AG without a modem' use case.
> This is something we never had as a requirement / objective. Phonesim is a
> development tool.  So of course it isn't trivial to setup, it isn't meant to
> be used in production in the first place.  The use of phonesim described in
> the PA wiki, while creative, is a giant hack ;)

Ok, so we definitely agree that ofono currently do not support HFP AG
without modem for desktop users. And this scenario is needed for
connecting bluetooth headsets, so we need some solution for it.

> Basically it all boils down to the fact that nobody has stepped up all this
> time to solve a particular use case you care about.  But blaming oFono for
> this is misguided.
> 
> So, if you want to solve the HFP AG without a modem case I fully support
> your efforts.

Ok! So which options do we have?

> Perhaps this can even be solved in oFono itself (since it already does 90%
> of what you want) by making the modem requirement optional.  What we could
> do for example is to create a dummy modem if an AG connection is requested
> and no other suitable modems are detected in the system.  The resultant AG
> wouldn't have any call control capability, it could still be used for
> transferring audio data, battery, etc.  If you want to pursue this, we can
> brainstorm further.

Well, if this would work automatically without any user interaction or
without special setup, it seems to be usable.

But what is needed from this implementation in ofono? Basically API for
each functionality designed in hsphfod daemon. And one of it is also
support for HSP profile (with CSR and Apple extensions).

I'm not against for it, but I thought that having functionality which is
not related to telephony / modem you would not want to see in ofono
project (like linux uinput layer for button events or API for displaying
raw text on embedded display; or CSR audio codec negotiation).

So how do you see possibility to have also HSP profile in ofono? So have
one place which would provide audio API for SCO? Because this is a big
requirements from audio software side, to not use 4 different APIs to
access SCO sockets (and its rfcomm / SLC configuration) in HSP and HFP
profiles.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Pali Rohár]

[-- Attachment #1: Type: text/plain, Size: 10486 bytes --]

On Friday 20 December 2019 23:46:57 Pali Rohár wrote:
> Hi!
> 
> On Friday 20 December 2019 15:19:01 Denis Kenzior wrote:
> > Hi Pali,
> > 
> > > > There have been one or two implementations of AG role fully external to
> > > > oFono.  These implementations simply used the existing oFono APIs to drive
> > > > the modem.
> > > 
> > > bluez & pulseaudio developers told me that it would be a good idea to
> > > avoid implementing a new AT parser for telephony stack. And rather use
> > > ofono implementation for telephony part...
> > 
> > In my opinion there's nothing scary about AT parsing.  In fact that is the
> > easiest part of this whole venture.  If you don't want to roll your own
> > parser, you can borrow one from the oFono project.  We already solved this
> > nicely in the form of the gatchat library.  You could incorporate this into
> > your project (if it is GPL compatible).  Or you could wait until we port
> > gatchat to ell which will be under LGPL license.
> > 
> > > 
> > > But if I should use existing DBus API provided by ofono, it means that I
> > > need to do parsing of all AT commands (including telephony) and
> > > translate them to ofono DBus API.
> > 
> > I think you will need to do this regardless.  Otherwise I fail to see how
> > you prevent one 'agent' from consuming AT commands it shouldn't be. This is
> > a possibility you need to consider, whether it happens by accident or
> > maliciously.
> 
> Some subset of AT commands are needed to parse and interpret. But not
> telephony commands and having up-to-date internal telephony state.
> 
> > > 
> > > I agree, this should work and there is not need to modify ofono. But it
> > > means that in hsphfpd daemon I need to have full AT parser for all
> > > telephony commands and it was something which bluez / pa developers
> > > thought that should be avoided. Therefore I come up with idea that
> > > telephony commands would be handled by external Telephony Agent, which
> > > can be ofono.
> > 
> > Understood.  But I think the metric function was selected inappropriately in
> > this case.  My opinion is that you should have started with what the overall
> > architecture should look like; you should not have based design decisions on
> > which parts might be a little hard to implement.
> > 
> > > 
> > > > You could do that.  But as I said, we rejected such a design a
> > > > long time ago due to complexity and other issues.
> > > 
> > > Anyway, what is the problem with accepting modem socket in ofono via
> > > DBus and starts talking with it like with any other modem which ofono
> > > supports? Currently ofono already takes modem socket from bluez via DBus
> > > API, so in same way hsphfpd can pass modem socket to ofono. Basically
> > > ofono then can reuse same code which already uses for sockets from
> > > bluez, just it do not have to parse and interpret audio related AT
> > > commands (as these are handled by hsphpfd itself).
> > > 
> > > What are exact issues? I do not see complexity at ofono part (as has
> > > already everything implemented) and currently I do not see those "other"
> > > issues.
> > 
> > The issues are many.  And really the question is not whether it 'could be'
> > done, but whether it 'should be' done.  Let me describe a couple examples:
> > 
> > - In the case of HF role (1), oFono already provides all the necessary APIs.
> > So put yourself in oFono's maintainer shoes.  What would we gain by
> > supporting almost the same but different mechanism?  We would have to
> > introduce a new hfp_hf plugin, one that is almost identical, but different
> > to hfp_hf_bluez5 plugin.
> 
> Yes, this would be needed, but because code os very similar it could be
> reused from one common place.
> 
> > These two plugins would have coexistence issues,
> > which would add more complexity.  Then there's the impact on PulseAudio and
> > other users.  How do they know when to use the HandsfreeAudio API vs some
> > external API?
> 
> Because pulseaudio has already own implementation of HSP profile and
> some kind of ofono implementation (which you named below "giant hack")
> it already needs to handle such problem.
> 
> But solution should be relatively simple. If we decide that new daemon
> is "new proper way" then it would have higher priority as current HFP
> API by ofono. So if hsphfpd is registered on dbus && hsphfpd say that it
> is active, then use hsphfpd. Otherwise if ofono is registered on dbus
> and say that device is active/connected use ofono.
> 
> > Supporting this new way buys us a lot of extra code /
> > complexity with no value added.
> 
> Value is support for HSP profile and support for HFP AG role without
> modem. And it would provide (for PA) unified same interface as for HFP
> HF role and HFP AG role with modem. I think this is a big value for PA
> (or bluez alsa or pipewire) to have one API which would handle all HSP
> and HFP profile/role combinations.
> 
> > - The other example is more practical. HFP Service Level Connection (SLC)
> > establishment is actually quite tricky.  There are certain limitations on
> > what can and cannot be done prior to SLC establishment, including how audio
> > handling is done.
> 
> I know :-) I already implemented prototype implementation to check and
> see how complicated it is and if API make sense and how hard it is for
> agents (audio - pulseaudio) implement and maintain it.
> 
> > Unfortunately, codec negotiation, indicator negotiation,
> > and feature negotiation are part of the SLC. oFono already solves all of
> > this and handles all of it nicely.
> 
> CSR codecs are not supported nor implemented in ofono. It is more
> complicated as HFP codecs... and needs a new API for audio application.
> Another value which brings my hsphfpd is that it handles these CSR
> codecs and provide API for audio application to use them.
> 
> > We have passed all relevant
> > certification testing.  It is very unclear how you plan to handle this (or
> > whether you realistically even can) in your architecture when the
> > responsibilities are split between the various daemons.  So again, oFono has
> > nothing to gain here...
> 
> I was not thinking about certification. It is not something which I
> could do.... And also pulseaudio itself do not have certifications.
> 
> > > 
> > > You suggested to use phone simulator together with ofono and then
> > > starts extending / patching phone simulator to supports all needed parts
> > > which are in my hsphfpd design (battery status, button press, codec
> > > selection)?
> > > 
> > 
> > Not quite.  I suggested you expand oFono's emulator implementation (for AG
> > role) and its DBus APIs (for HF role) to support the new vendor specific
> > features that you want.
> > 
> > Forget about the phone simulator, it is really irrelevant for what you're
> > trying to accomplish.
> 
> Ok. I thought that phone simulator = ofono emulator. I just saw that
> phone simulator which is described in pulseaudio documentation.
> 
> > > Also how to handle the main problem of phone simulator that it is too
> > > much complicated to setup it on desktop? Looking at the steps...
> > > 
> > > https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Bluetooth/#index5h2
> > > 
> > > ... that desktop user needs to run nontrivial commands in command like,
> > > plus creating configuration file only just to connect bluetooth headset
> > > is ridiculous and non-acceptable for desktop application.
> > > 
> > > If this problem is not fixed, ofono and phone simulator are not usable
> > > as "main" software implementation of HFP profile for usage of bluetooth
> > > headsets on Linux.
> > 
> > oFono was never advertised as solving the 'HFP AG without a modem' use case.
> > This is something we never had as a requirement / objective. Phonesim is a
> > development tool.  So of course it isn't trivial to setup, it isn't meant to
> > be used in production in the first place.  The use of phonesim described in
> > the PA wiki, while creative, is a giant hack ;)
> 
> Ok, so we definitely agree that ofono currently do not support HFP AG
> without modem for desktop users. And this scenario is needed for
> connecting bluetooth headsets, so we need some solution for it.
> 
> > Basically it all boils down to the fact that nobody has stepped up all this
> > time to solve a particular use case you care about.  But blaming oFono for
> > this is misguided.
> > 
> > So, if you want to solve the HFP AG without a modem case I fully support
> > your efforts.
> 
> Ok! So which options do we have?
> 
> > Perhaps this can even be solved in oFono itself (since it already does 90%
> > of what you want) by making the modem requirement optional.  What we could
> > do for example is to create a dummy modem if an AG connection is requested
> > and no other suitable modems are detected in the system.  The resultant AG
> > wouldn't have any call control capability, it could still be used for
> > transferring audio data, battery, etc.  If you want to pursue this, we can
> > brainstorm further.
> 
> Well, if this would work automatically without any user interaction or
> without special setup, it seems to be usable.
> 
> But what is needed from this implementation in ofono? Basically API for
> each functionality designed in hsphfod daemon. And one of it is also
> support for HSP profile (with CSR and Apple extensions).
> 
> I'm not against for it, but I thought that having functionality which is
> not related to telephony / modem you would not want to see in ofono
> project (like linux uinput layer for button events or API for displaying
> raw text on embedded display; or CSR audio codec negotiation).
> 
> So how do you see possibility to have also HSP profile in ofono? So have
> one place which would provide audio API for SCO? Because this is a big
> requirements from audio software side, to not use 4 different APIs to
> access SCO sockets (and its rfcomm / SLC configuration) in HSP and HFP
> profiles.

Hi Denis! Can you look at this email? I would like to know what could be
next steps, specially if ofono (in some way) could be extended for all
use-cases and would be usable for Linux desktop. Or not and I rather
should continue with my hsphfpd proposal.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Denis Kenzior]

Hi Pali,

<snip>

>> I think you will need to do this regardless.  Otherwise I fail to see how
>> you prevent one 'agent' from consuming AT commands it shouldn't be. This is
>> a possibility you need to consider, whether it happens by accident or
>> maliciously.
> 
> Some subset of AT commands are needed to parse and interpret. But not
> telephony commands and having up-to-date internal telephony state.

Please think some more about what I said.  You will need to parse every 
AT command in your daemon, no way around that.  You are right that you 
do not need to keep track of the telephony state, but that is besides 
the point.  So if you need an AT parser anyway, the whole reasoning for 
the proposed architecture starts to look shaky.

<snip>

> 
>> - The other example is more practical. HFP Service Level Connection (SLC)
>> establishment is actually quite tricky.  There are certain limitations on
>> what can and cannot be done prior to SLC establishment, including how audio
>> handling is done.
> 
> I know :-) I already implemented prototype implementation to check and
> see how complicated it is and if API make sense and how hard it is for
> agents (audio - pulseaudio) implement and maintain it.
> 
>> Unfortunately, codec negotiation, indicator negotiation,
>> and feature negotiation are part of the SLC. oFono already solves all of
>> this and handles all of it nicely.
> 
> CSR codecs are not supported nor implemented in ofono. It is more
> complicated as HFP codecs... and needs a new API for audio application.
> Another value which brings my hsphfpd is that it handles these CSR
> codecs and provide API for audio application to use them.
> 

Again, you're not addressing my main point.  Codec negotiation is part 
of SLC establishment.  SLC has both telephony and audio aspects. 
They're inseparable.  Your architecture fails to address this...

CSR codecs are not part of SLC and can be bolted on later.  I already 
told you that oFono can easily be changed to support this.

>> We have passed all relevant
>> certification testing.  It is very unclear how you plan to handle this (or
>> whether you realistically even can) in your architecture when the
>> responsibilities are split between the various daemons.  So again, oFono has
>> nothing to gain here...
> 
> I was not thinking about certification. It is not something which I
> could do.... And also pulseaudio itself do not have certifications.

So again, no reason for us to get involved :)

Bottom line is there's no value for us in this architecture.  If you 
want to use the existing oFono APIs, that's fine.  But we're not adding 
a plugin for taking arbitrary AT commands from some other daemon :)

<snip>

>> Perhaps this can even be solved in oFono itself (since it already does 90%
>> of what you want) by making the modem requirement optional.  What we could
>> do for example is to create a dummy modem if an AG connection is requested
>> and no other suitable modems are detected in the system.  The resultant AG
>> wouldn't have any call control capability, it could still be used for
>> transferring audio data, battery, etc.  If you want to pursue this, we can
>> brainstorm further.
> 
> Well, if this would work automatically without any user interaction or
> without special setup, it seems to be usable.
> 
> But what is needed from this implementation in ofono? Basically API for
> each functionality designed in hsphfod daemon. And one of it is also
> support for HSP profile (with CSR and Apple extensions).

Start a separate thread on ofono for this.  I already gave you hints on 
how to solve the 'AG without a real modem' use case.  That would seem to 
be the biggest 'win' and it should be fairly easy to make this work.

> 
> I'm not against for it, but I thought that having functionality which is
> not related to telephony / modem you would not want to see in ofono
> project (like linux uinput layer for button events or API for displaying
> raw text on embedded display; or CSR audio codec negotiation).
> 
> So how do you see possibility to have also HSP profile in ofono? So have
> one place which would provide audio API for SCO? Because this is a big
> requirements from audio software side, to not use 4 different APIs to
> access SCO sockets (and its rfcomm / SLC configuration) in HSP and HFP
> profiles.
> 

HSP is a separate issue.  Maybe we can handle it like the 'dundee' 
daemon inside oFono (which handles Bluetooth DUN profile).  In other 
words have a dedicated daemon for hsp support that reuses the relevant 
bits of oFono and maybe exposes the same APIs (i.e the ones documented 
in doc/handsfree-audio-api.txt).  That would make life for PulseAudio 
pretty easy.

Regards,
-Denis

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

[Pali Rohár]

[-- Attachment #1: Type: text/plain, Size: 6238 bytes --]

On Tuesday 07 January 2020 11:35:48 Denis Kenzior wrote:
> Hi Pali,
> 
> <snip>
> 
> > > I think you will need to do this regardless.  Otherwise I fail to see how
> > > you prevent one 'agent' from consuming AT commands it shouldn't be. This is
> > > a possibility you need to consider, whether it happens by accident or
> > > maliciously.
> > 
> > Some subset of AT commands are needed to parse and interpret. But not
> > telephony commands and having up-to-date internal telephony state.
> 
> Please think some more about what I said.  You will need to parse every AT
> command in your daemon, no way around that.  You are right that you do not
> need to keep track of the telephony state, but that is besides the point.
> So if you need an AT parser anyway, the whole reasoning for the proposed
> architecture starts to look shaky.

I do not need to parse and interpret all AT commands. Telephony commands
does not have to parsed and interpreted. They can be forwarded to
telephony agent (if connected) OR replied with ERROR as a result that
command is not supported.

> 
> > 
> > > - The other example is more practical. HFP Service Level Connection (SLC)
> > > establishment is actually quite tricky.  There are certain limitations on
> > > what can and cannot be done prior to SLC establishment, including how audio
> > > handling is done.
> > 
> > I know :-) I already implemented prototype implementation to check and
> > see how complicated it is and if API make sense and how hard it is for
> > agents (audio - pulseaudio) implement and maintain it.
> > 
> > > Unfortunately, codec negotiation, indicator negotiation,
> > > and feature negotiation are part of the SLC. oFono already solves all of
> > > this and handles all of it nicely.
> > 
> > CSR codecs are not supported nor implemented in ofono. It is more
> > complicated as HFP codecs... and needs a new API for audio application.
> > Another value which brings my hsphfpd is that it handles these CSR
> > codecs and provide API for audio application to use them.
> > 
> 
> Again, you're not addressing my main point.  Codec negotiation is part of
> SLC establishment.  SLC has both telephony and audio aspects. They're
> inseparable.  Your architecture fails to address this...

Why? Codec negotiation is part of SLC, but codec can be changed prior
opening SCO connection.

How my architecture failed? What to address?

I implemented it in my prototype and it is working. So I do not
understand your point.

> CSR codecs are not part of SLC and can be bolted on later.  I already told
> you that oFono can easily be changed to support this.

I'm not disagreeing with this.

> > > We have passed all relevant
> > > certification testing.  It is very unclear how you plan to handle this (or
> > > whether you realistically even can) in your architecture when the
> > > responsibilities are split between the various daemons.  So again, oFono has
> > > nothing to gain here...
> > 
> > I was not thinking about certification. It is not something which I
> > could do.... And also pulseaudio itself do not have certifications.
> 
> So again, no reason for us to get involved :)
> 
> Bottom line is there's no value for us in this architecture.  If you want to
> use the existing oFono APIs, that's fine.  But we're not adding a plugin for
> taking arbitrary AT commands from some other daemon :)

I can say exactly same. I'm not interested in any certification, I do
not see reason to care about it. Pulseaudio does not have any and is the
de-facto standard way how to use bluetooth audio on Linux.

> > > Perhaps this can even be solved in oFono itself (since it already does 90%
> > > of what you want) by making the modem requirement optional.  What we could
> > > do for example is to create a dummy modem if an AG connection is requested
> > > and no other suitable modems are detected in the system.  The resultant AG
> > > wouldn't have any call control capability, it could still be used for
> > > transferring audio data, battery, etc.  If you want to pursue this, we can
> > > brainstorm further.
> > 
> > Well, if this would work automatically without any user interaction or
> > without special setup, it seems to be usable.
> > 
> > But what is needed from this implementation in ofono? Basically API for
> > each functionality designed in hsphfod daemon. And one of it is also
> > support for HSP profile (with CSR and Apple extensions).
> 
> Start a separate thread on ofono for this.  I already gave you hints on how
> to solve the 'AG without a real modem' use case.  That would seem to be the
> biggest 'win' and it should be fairly easy to make this work.

Ok, I will start a separate thread.

> > 
> > I'm not against for it, but I thought that having functionality which is
> > not related to telephony / modem you would not want to see in ofono
> > project (like linux uinput layer for button events or API for displaying
> > raw text on embedded display; or CSR audio codec negotiation).
> > 
> > So how do you see possibility to have also HSP profile in ofono? So have
> > one place which would provide audio API for SCO? Because this is a big
> > requirements from audio software side, to not use 4 different APIs to
> > access SCO sockets (and its rfcomm / SLC configuration) in HSP and HFP
> > profiles.
> > 
> 
> HSP is a separate issue.

It is not separate issue. It is one of the main issues. If ofono is not
going to support HSP then there is absolutely no reason why to use ofono
and extend it to support a new features which currently do not support
(like CSR codecs which are in both HSP and HFP profiles). Basically
without it ofono is unusable for handling bluetooth audio on Linux
desktop.

> Maybe we can handle it like the 'dundee' daemon
> inside oFono (which handles Bluetooth DUN profile).  In other words have a
> dedicated daemon for hsp support that reuses the relevant bits of oFono and
> maybe exposes the same APIs (i.e the ones documented in
> doc/handsfree-audio-api.txt).  That would make life for PulseAudio pretty
> easy.
> 
> Regards,
> -Denis

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Proposal for a new API and usage of Bluetooth HSP and HFP profiles on Linux

[Pali Rohár]

[-- Attachment #1: Type: text/plain, Size: 4701 bytes --]

Hello! Below is my email from December 2019 about a new and I think
proper way how to handle Bluetooth HSP and HFP profiles on Linux desktop
system which do not have any cellular modem or other mobile hardware.

I would like to ask audio people and teams (bluez-alsa, pipewire) and
also other people around. Are you interested in using my hsphfpd DBus
API in audio applications? And if yes, would you implement this API in
audio routing software? Do you have some comments or review of hsphfpd
API? Or would you like to somehow extend it? Also who could be
interesting in helping, developing, testing or maintaining hsphfpd
daemon itself?

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]