Linux-Bluetooth Archive on lore.kernel.org
 help / color / Atom feed
From: "Pali Rohár" <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
Date: Wed, 4 Dec 2019 18:05:21 +0100
Message-ID: <20191204170521.mfo5qtoy65raetwc@pali> (raw)
In-Reply-To: <190b130f-bc84-4af1-a807-5b5fbef3f166@www.fastmail.com>

[-- Attachment #1: Type: text/plain, Size: 2257 bytes --]

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 this 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 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..

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 PulseAudio (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...

... 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, ...).

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

  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
2019-12-04 17:05       ` Pali Rohár [this message]
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=20191204170521.mfo5qtoy65raetwc@pali \
    --to=pali.rohar@gmail.com \
    --cc=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=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