Linux-Bluetooth Archive on
 help / color / Atom feed
* Re: HSP/HFP ofono bluetooth support for Linux desktop
       [not found] <20200107192311.efit6zftt27encdc@pali>
@ 2020-01-08 11:40 ` Pali Rohár
       [not found] ` <>
  1 sibling, 0 replies; 2+ messages in thread
From: Pali Rohár @ 2020-01-08 11:40 UTC (permalink / raw)
  To: ofono, Denis Kenzior; +Cc: linux-bluetooth

CCing also bluez developers as they may be interested in discussion how
is HSP/HFP going to be implemented and used on Linux desktop.

On Tuesday 07 January 2020 20:23:11 Pali Rohár wrote:
> Hello!
> Denis wanted from me to start a new thread, so I'm doing it.
> As I wrote in different thread current state of HSP and HFP bluetooth
> profiles on Linux desktop is in very bad state, specially usage of SCO
> audio connection for audio applications (e.g. pulseaudio). See all
> details in that email. I proposed a solution for it via hsphfpd daemon
> with its prototype implementation, but Denis wrote that ofono could be a
> better solution.
> Part of HSP and HFP bluetooth profiles is AT socket connection which
> needs to handle, parse and interpret all needed AT commands.
> ofono project seems to be a candidate for handling AT socket on Linux
> desktop, but in current state it is unusable. For audio application
> (pulseaudio) there are required following features which ofono currently
> missing:
> * ability to connect HFP profiles in HF role without any modem
>   (desktop computers do not have to have any modem). ofono currently
>   does not support establishing HFP connection in HF role when computer
>   does not have any modem
> * support for HSP profiles (in both HS and AG roles). ofono currently
>   does not support HSP profile at all
> These two missing features are main blockers why ofono is unusable for
> desktop/laptop usage as AT parser/handler for bluetooth HSP/HFP
> profiles.
> Denis wrote that fixing first issue would be possible by automatically
> registering some fake dummy modem (when there is no in system) and
> connecting it with HFP profile in HF role.
> Do you have a reasonable solution also for second issue?
> If above two issue could be solved I can write a list of all other
> issues which are needed to be solved for providing HSP/HFP support on
> Linux desktops.

Pali Rohár

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: HSP/HFP ofono bluetooth support for Linux desktop
       [not found] ` <>
@ 2020-01-08 21:25   ` Pali Rohár
  0 siblings, 0 replies; 2+ messages in thread
From: Pali Rohár @ 2020-01-08 21:25 UTC (permalink / raw)
  To: Denis Kenzior; +Cc: ofono, linux-bluetooth

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


On Wednesday 08 January 2020 14:34:32 Denis Kenzior wrote:
> Hi Pali,
> > Do you have a reasonable solution also for second issue?
> > 
> HSP profile has always been a problem child.  It isn't really all that
> useful as a profile, and given how minimal it is, the right place for it
> always seemed to be inside Pulse Audio itself.  This is what Marcel & I
> agreed upon back about 8-9 years ago anyway.
> You are advocating that HSP is still useful, particularly with vendor
> extensions.  Which is fair enough, but now you have to figure out how and
> where to put this support.
> As mentioned earlier, one idea you can explore is to create a small daemon
> (or maybe it can even be part of ofonod itself) that will handle HSP
> client/server roles.  See for example the dundee daemon that is part of
> ofono.git.  dundee handles Bluetooth DUN profile and might be a good model /
> starting point for what you're trying to accomplish.

I looked at dundee, but it does it is separated service, not on org.ofono
So it looks like it does not fit into HSP / HFP needs.

Currently you can list all audio cards by DBus call:

"org.ofono", "/", "org.ofono.HandsfreeAudioManager", "GetCards"

and so this (or some new) call should list all HSP and HFP devices/cards
for audio application (pulseaudio).

Audio application (e.g. pulseaudio) really do not want to handle two
separate services to monitor and process HSP/HFP devices.

For audio application are HSP and HFP devices equivalent, they provide
same features: SCO socket, API for controlling microphone and speaker
gain; plus optionally specify used codec.

So having two separate services which fully divided for audio
application purpose does not make sense.

So it is possible that both HSP and HFP audio cards would be available
via one audio API? Because I do not see how it could be done via design
like dundee.

> You can then implement the same API interfaces for setting up the HSP audio
> stream as oFono does today (i.e.,

This API is unusable for both HSP and HFP audio streams. In pulseaudio
it is somehow used, but it is not suitable.

In part of designing hsphfpd I created a new DBus API for audio
application to fit for audio daemons. See org.hsphfpd.AudioAgent:

Main objection for handsfree-audio-api.txt is that it does not provide
information about locally used codec and somehow mixes air codec and
local codec. In my hsphfpd.txt I used term "AgentCodec" for bluetooth
local codec and term "AirCodec" for bluetooth air codec format.

Another objection against handsfree-audio-api.txt API is that it is
bound to HF codecs (via number) and does not support for pass e.g. CSR

What is completely missing in that API is controlling volume level.

And also API does not provide socket MTU information or ability to
change/specify which codec would be used.

So something like org.hsphfpd.AudioAgent API in my hsphfpd design would
be needed.

> which would make PulseAudio's job much easier, since the audio stream
> aspects would be essentially identical to HFP.  If you're part of oFono's
> tree, then in theory many implementation aspects could be reused.
> If you want to provide some higher-level APIs for external applications,
> then HSP specific interfaces (APIs) can be added as needed.

Non-audio APIs which are needed to export (for both HSP and HFP profiles):

* battery level (0% - 100%)
* power source (external, battery, unknown)
* ability to send "our laptop" battery level and power source to remote device
* send text message to embedded display
* process button press event (exported via linux kernel uinput)

(plus all telephony related operations, but those are already supported
and provided by ofono)

> If you decide this is something you want to pursue, then I'm happy to host
> this in the oFono tree.
> Regards,
> -Denis

Pali Rohár

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, back to index

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20200107192311.efit6zftt27encdc@pali>
2020-01-08 11:40 ` HSP/HFP ofono bluetooth support for Linux desktop Pali Rohár
     [not found] ` <>
2020-01-08 21:25   ` Pali Rohár

Linux-Bluetooth Archive on

Archives are clonable:
	git clone --mirror linux-bluetooth/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-bluetooth linux-bluetooth/ \
	public-inbox-index linux-bluetooth

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone