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.
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
