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

From: "Pali Rohár" <pali.rohar@gmail.com>
To: Denis Kenzior <denkenz@gmail.com>
Cc: Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
	"linux-bluetooth@vger.kernel.org"
	<linux-bluetooth@vger.kernel.org>, Tanu Kaskinen <tanuk@iki.fi>,
	General PulseAudio Discussion 
	<pulseaudio-discuss@lists.freedesktop.org>,
	ofono@ofono.org, devkit-devel@lists.freedesktop.org,
	Bastien Nocera <hadess@hadess.net>, Georg Chini <georg@chini.tk>,
	Russell Treleaven <rtreleaven@bunnykick.ca>,
	Arun Raghavan <arun@arunraghavan.net>,
	Marcel Holtmann <marcel@holtmann.org>,
	Sebastian Reichel <sre@ring0.de>, Pavel Machek <pavel@ucw.cz>
Subject: Re: [pulseaudio-discuss] Proposal for a new API and usage of Bluetooth HSP and HFP profiles on Linux
Date: Wed, 18 Dec 2019 18:36:32 +0100	[thread overview]
Message-ID: <20191218173632.aqdmdhutu3ruezck@pali> (raw)
In-Reply-To: <20191218172828.vfie4su2whts2fqh@pali>

[-- 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 --]