Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Wed, 4 Dec 2019 18:05:21 +0100
From:   Pali =?utf-8?B?Um9ow6Fy?= <pali.rohar@gmail.com>
To:     Arun Raghavan <arun@arunraghavan.net>
Cc:     Tanu Kaskinen <tanuk@iki.fi>,
        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
Message-ID: <20191204170521.mfo5qtoy65raetwc@pali>
References: <20191201185740.uot7zb2s53p5gu7z@pali>
 <508d35f29c2abc26af15e232a38d3ca53eb33706.camel@iki.fi>
 <20191202184512.rx6p63c6axztnwrw@pali>
 <190b130f-bc84-4af1-a807-5b5fbef3f166@www.fastmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
        protocol="application/pgp-signature"; boundary="fjnfaeynkyyttc45"
Content-Disposition: inline
In-Reply-To: <190b130f-bc84-4af1-a807-5b5fbef3f166@www.fastmail.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk


--fjnfaeynkyyttc45
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wednesday 04 December 2019 20:45:23 Arun Raghavan wrote:
> Broadly, I think this is a good thing to do. My main concern is having th=
is be adequately maintained over a longer period of time.

I already prepared prototype implementation, so I know how hard is to
write or maintain this new daemon.

Are there any interested people in either implementing, maintaining or
in other way helping with this project?

The main problem in maintaining this HSP/HFP codebase I see that I do
not have enough testing devices. As we know lot of manufactures produce
devices which are not compliant to standards and this needs to be
handled in HSP/HFP codebase.

> 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 n=
ode 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..

PipeWire or any other audio server (jack or bluez-alsa) can benefit from
this hsphfpd daemon that it does not have to implement (again) parsing
and interpreting AT commands (as needed for HFP standard).

For PipeWire developers: Do you have any special requirements for this
hsphfpd daemon which are needed for processing of audio?

See proposed DBus interface, specially "Audio Agent hierarchy":
https://github.com/pali/hsphfpd-prototype/raw/prototype/hsphfpd.txt

> This would also have the benefit of moving codec dependencies out of Puls=
eAudio (which I'll help mitigate in other ways within PulseAudio anyway).

hsphfpd just prepares SCO audio socket and then via DBus pass it to
target application (pulseaudio, pipewire, jacks, ...). And it is up to
the audio application to do codec processing. hsphfpd is not going to do
anything with audio samples or codecs. So this does not help directly...

=2E.. But I'm planing to try to separate A2DP code from pulseaudio into
some external library which would not depend on pulseaudio. So this
library can help all audio server projects to not re-implement again and
again A2DP (and HSP/HFP) audio processing. This library should do all
needed codec stuff (encoding, decoding, setup of A2DP, ...).

--=20
Pali Roh=C3=A1r
pali.rohar@gmail.com

--fjnfaeynkyyttc45
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQS4VrIQdKium2krgIWL8Mk9A+RDUgUCXefnTwAKCRCL8Mk9A+RD
UtizAJ4jebcbx+300lfUIYwDo6/CcO8AsQCcCrEwdRrkh+X8gbrX5/qLSQQ3YsQ=
=uINE
-----END PGP SIGNATURE-----

--fjnfaeynkyyttc45--