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

["Pali Rohár" <pali.rohar@gmail.com>]

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