[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 at 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 at gmail.com