[pulseaudio-discuss] Bluetooth HSP and HFP support in pulseaudio

Pali Rohár pali.rohar at gmail.com
Tue Apr 28 17:08:41 UTC 2020


On Tuesday 28 April 2020 19:25:12 Tanu Kaskinen wrote:
> It's not helpful to repeat that the ofono code needs massive changes as
> a precondition to having a hsphfpd backend without specifying those
> changes, because it sounds so unlikely to be true. Later in your mail
> you mentioned that the profile switching needs to be changed from
> synchronous to asynchronous. Good, now there's something concrete to
> discuss.

ofono API does not support closing and unregistering profile connection:
https://git.kernel.org/pub/scm/network/ofono/ofono.git/tree/doc/handsfree-api.txt
https://git.kernel.org/pub/scm/network/ofono/ofono.git/tree/doc/handsfree-audio-api.txt
Without it, it is not possible to implement coexistency. There is only
API for unregistring agent, which is not enough. ofono API does not
support HSP profiles at all.

So HSP and HSP profile switching is not possible to implement with this
backend.

Next problem is that this ofono API does not provide MTU of acquired SCO
socket. Without it it not possible to implement correct handling of
buffer sizes, which is e.g. used by my changes for hsphfpd
implementation.

I already wrote all those problems in previous emails and I really do
not want to copy+paste content of my previous emails.

ofono API is basically broken design for audio applications and proper
usage needs to be changed and fixed. But I already did it, and it is
what resulted in hsphfpd API.

> > I do not want to disagree that for some people it works, I have no
> > reason to not trust Georg that it works for him.
> >
> > > Even if hsphfpd could do everything that oFono does, it's a new
> > > project, I'd call it experimental at this stage. I don't want to tell
> > > users that they have to change their working software stack in order to
> > > keep old features when updating to a new PulseAudio version.
> > > 
> > > If oFono is not working for you and you therefore can't test it, then
> > > don't test it. Fixing existing bugs in oFono isn't your job. Just avoid
> > > touching the oFono code as much as possible.
> > 
> > I really cannot implement and use hsphpfd backend coexistence with
> > current ofono backend. And I cannot implement (asynchronous) support for
> > profile switching between A2DP, HSP and HFP profile which I did in that
> > published code with current ofono backend. This profile switching is
> > required for hsphfpd and it is not possible to implement it without
> > touching and fixing ofono code. So this was also another reason why I
> > removed it from my WIP codebase.
> 
> Ok, so you need to change how profile switching works. Can you abstract
> away the differences between asynchronous and synchronous profile
> switching? Like call a different card_set_profile() implementation with
> ofono (this is just an example).

Why? I said that I spent to much time with that ofono and I really do
not want to invest more time in ofono backend which is basically
incompatible with hsphpfd daemon.

> To me it seems that it should be entirely possible to move the old
> bluez-util.c code to the ofono backend for those parts that cause major
> problems with adapting the ofono code. In the worst case the whole
> bluetooth infrastructure and modules need to be duplicated, and I
> really hope we don't have to go there, but that's still better than
> removing functionality.	

Well, why you do not try to yourself? You are talking about it like
something easy to implement, debug and deliver to users.

I also spend too much time trying to fix internal pulseaudio HSP profile
implementation and every time I think it works, something else appeared
to be broken again. But finally I was able to do it.

Why you are still trying to keep this ofono backend as is as we know
that is cause interopability problems, have broken API for audio, ofono
community is not willing to fix it and maintain it and moreover there is
replacement in my new hsphpfd design?

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


More information about the pulseaudio-discuss mailing list