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

[Tanu Kaskinen]

On Tue, 2020-04-28 at 16:12 +0200, Pali Rohár wrote:
> On Tuesday 28 April 2020 16:33:01 Tanu Kaskinen wrote:
> > On Tue, 2020-04-28 at 13:08 +0200, Pali Rohár wrote:
> > > On Tuesday 28 April 2020 13:57:42 Tanu Kaskinen wrote:
> > > > Just to chime in on the ofono removal issue: I'm also of the opinion
> > > > that removing ofono support is not an option.
> > > 
> > > Well, in this case you have 3 choices:
> > > 
> > > * Fix it yourself or find somebody who will work on it and would maintain this code in future
> > > * Try asking ofono community to start cooperate and tell them start
> > >   working and fixing that pulseaudio ofono code (including future maintenance)
> > > * Do not take my now fully working hsphpfd support in pulseaudio and do not implement HSP and HFP profiles properly in pulseaudio at all
> > > 
> > > I'm not going to spend another time with ofono and its buggy audio
> > > support, I tried it and it was waste of time, and specially now when
> > > ofono community is not interested in cooperation; and I have working
> > > better alternative suitable also for supporting other parts (like
> > > battery support, input button support, etc...)
> > > 
> > > And... what is the purpose of buggy ofono backend support in pulseaudio,
> > > now when I provided better code HSP and HFP profiles?
> > 
> > Last year a Collabora developer made a patch that fixed a crash in the
> > oFono backend. I assume their customer is using PulseAudio with oFono,
> > so I would also assume that it's not so buggy that it's useless (and
> > indeed, Georg reports that it's working fine for him). oFono also
> > integrates HFP to the telephony stack, which hsphfpd doesn't do.
> 
> Also there are lot of users for which HFP profile via current ofono
> pulseaudio implementation does not work, see tons of bugs in issue
> tracker and tons of blames for pulseaudio and its totally broken and
> non-working microphone bluetooth support on internet forums. And I
> understand it, for majority of people it does not work.
> 
> Really look at reality, bluetooth microphone support in pulseaudio is
> worse then poor. And *nobody* did anything in pulseaudio for years.
> I was able to implement now everything related to bluetooth audio.

That's great, thank you for your work!

> Is that Collabora developer going to implement all missing, needed and
> broken stuff in next days? Or at least next weeks/months? If not, who
> other is going to handle all those bluetooth problems? Or do you think
> that everything is working fine and there is no need to do anything with
> bluetooth related code?

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.

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

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.	

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk