Linux-Bluetooth Archive on lore.kernel.org
 help / color / Atom feed
From: "Arun Raghavan" <arun@arunraghavan.net>
To: "Pali Rohár" <pali.rohar@gmail.com>, "Tanu Kaskinen" <tanuk@iki.fi>
Cc: "PulseAudio Discussion"
	<pulseaudio-discuss@lists.freedesktop.org>,
	linux-bluetooth@vger.kernel.org, ofono@ofono.org,
	devkit-devel@lists.freedesktop.org,
	"Bastien Nocera" <hadess@hadess.net>,
	"Georg Chini" <georg@chini.tk>,
	"Russell Treleaven" <rtreleaven@bunnykick.ca>,
	"Luiz Augusto von Dentz" <luiz.dentz@gmail.com>,
	"Marcel Holtmann" <marcel@holtmann.org>,
	"Sebastian Reichel" <sre@ring0.de>, "Pavel Machek" <pavel@ucw.cz>,
	"Wim Taymans" <wim.taymans@gmail.com>,
	"George Kiagiadakis" <george.kiagiadakis@collabora.com>
Subject: Re: [pulseaudio-discuss] Proposal for a new API and usage of Bluetooth HSP and HFP profiles on Linux
Date: Wed, 04 Dec 2019 20:45:23 +0530
Message-ID: <190b130f-bc84-4af1-a807-5b5fbef3f166@www.fastmail.com> (raw)
In-Reply-To: <20191202184512.rx6p63c6axztnwrw@pali>

+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

  reply index

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-01 18:57 Pali Rohár
2019-12-02 17:01 ` [pulseaudio-discuss] " Tanu Kaskinen
2019-12-02 18:45   ` Pali Rohár
2019-12-04 15:15     ` Arun Raghavan [this message]
2019-12-04 17:05       ` Pali Rohár
2019-12-05  9:32     ` Pali Rohár
2019-12-02 19:49 ` Sebastian Reichel
2019-12-07 20:09 ` Pali Rohár
2019-12-09  9:43   ` George Kiagiadakis
2019-12-09 11:07     ` Pali Rohár

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=190b130f-bc84-4af1-a807-5b5fbef3f166@www.fastmail.com \
    --to=arun@arunraghavan.net \
    --cc=devkit-devel@lists.freedesktop.org \
    --cc=georg@chini.tk \
    --cc=george.kiagiadakis@collabora.com \
    --cc=hadess@hadess.net \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=luiz.dentz@gmail.com \
    --cc=marcel@holtmann.org \
    --cc=ofono@ofono.org \
    --cc=pali.rohar@gmail.com \
    --cc=pavel@ucw.cz \
    --cc=pulseaudio-discuss@lists.freedesktop.org \
    --cc=rtreleaven@bunnykick.ca \
    --cc=sre@ring0.de \
    --cc=tanuk@iki.fi \
    --cc=wim.taymans@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-Bluetooth Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-bluetooth/0 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/ https://lore.kernel.org/linux-bluetooth \
		linux-bluetooth@vger.kernel.org
	public-inbox-index linux-bluetooth

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-bluetooth


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git