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

[Georg Chini]

On 28.04.20 19:08, Pali Rohár wrote:
> 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?
>
Neither Tanu nor I want to say that things are easy and we both do not
expect you to fix the ofono backend. But people are using it to connect
their mobile and I have not seen many complaints concerning this.
The complaints are all about headset support which I agree is unusable
for the ofono backend and far from perfect for the native backend.

Personally I don't see a problem to remove the AG role support from
the ofono backend because nobody uses it. What I proposed earlier
- allow hsphfpd to disable the HFP HS role and keep a "legacy" ofono
backend for the HFP HS role - should not be that hard to implement
compared to all the time and work you already invested and it would
help us to keep users happy.