On 17.03.20 13:06, Pali Rohár wrote:
On Monday 16 March 2020 18:19:47 Tanu Kaskinen wrote:
On Sun, 2020-03-15 at 14:37 +0100, Pali Rohár wrote:
Hello! One month passed and I have not answer which solution would
pulseaudio choose for HSP and HFP support. Could you please really look
at my email about state of HSP / HFP support?
On Saturday 15 February 2020 22:33:10 Pali Rohár wrote:
If Linux desktop / laptop with pulseaudio want to support HFP profile
there are following options:
1) As written above, implement full HFP profile, therefore telephony
stack in pulseaudio and handle all users features in pulseaudio
(input devices, power devices, telephony features) including audio
features (wide band support, custom codec support). In this setup
pulseaudio would be incompatible with ofono and ofono must be stopped
on that computer to prevent ofono from taking rfcom socket.
2) Delegate all non-audio features of HSP and HFP profiles from 1) to
hsphfpd daemon and implement in pulseaudio only audio related
features via DBus API provided by hsphfpd daemon. In this setup
hsphfpd would own rfcom socket and via DBus API would communicate
with other applications (e.g. pulseaudio, upower). This setup is
incompatible with ofono, as ofono developers wrote that they do not
want to use this design and because ofono implements own handling of
HFP profiles, ofono daemon would need to be stopped on such machine
to prevent ofono from taking rfcom socket. So telephony functions would
not be supported until somebody write alternative telephony software
which would connect to hsphfpd as ofono devs do not want to use
hsphfpd.
3) In pulseaudio drop support for all desktop and laptop computers which
do not have connected cellular modem compatible with ofono. In this
way we could use ofono's HFP implementation for some basic audio
stuff. But no additional features (like battery status or input
buttons) would be provided. Also no custom codecs, etc.
4) In pulseaudio do not implement proper and full HFP profile support at
all. Just say to users, that if they want to use bluetooth HFP
headset, they have to change operating system from Linux to some
other which implement it.
5) Like 4) but be silent and do not say anything to users. Do not answer
to question from users about bluetooth HSP/HFP. Just do not do
anything.
...
So please, pulseaudio developers/maintainers, write what you think and
which option you choose and who would implement that option. Remember,
that silence means you automatically chose option 5) which would be rude
to all pulseaudio users.
Does really silence mean that option 5) was automatically chosen? I hope
that not.
If you have not had time to discuss, compare and choose solution, please
write at least that you are not going to choose option 5).
I have not had time to discuss.
I think it makes sense to try the hsphfpd approach, if you're motivated
to write and maintain that all by yourself (plus the integration code
in PulseAudio). With luck you'll find someone to help, but I'm not
aware of anyone who has time for that.
As I said, I can develop integration code for pulseaudio too. And also I
can maintain hsphfpd daemon.
I will try to find a time and prepare integration part for pulseaudio.
Georg said that it doesn't make sense to implement this only for PA,
but if you get it to a working state, I don't see why PipeWire (and
maybe alsa-bluez) wouldn't use it too.
Ok.
There's one other approach, however, that you seem to reject for a
reason that is not clear to me: if I understood correctly the
discussion with the oFono developers[1], they're open to implementing
everything hsphfpd does in oFono.
There is a main rejection in design, that HSP and HFP cannot be in one
service and therefore on ofono side it needs to be on two separated
places, plus target audio application (pulseaudio) would need to
implement two separate services and endpoints, one for HSP and one for
HFP, even for audio part they are same.
In my hsphfpd API, there is just one service for both HSP and HFP
profiles and audio application needs to implement communication with
just one service which provides audio socket (either from HSP or HFP).
They said they're not planning to add
the missing features, but they didn't say they would reject patches.
For comparison, I'm not really planning to add any features to
PulseAudio either (no time for that), but that doesn't mean I reject
features implemented by other people than me.
Another thing against ofono: it is modem connection software. Why such
software needs to be requirement for desktop system which do not have
any cellular (or other) modem?
Also more people prefer to use other modem connection software, e.g.
ModemManager. Now if we add requirement that ofono is crucial part for
bluetooth, then there would be another problem: How to use ModemManager
on system with bluetooth headset? Either ModemManager would have to
reimplement everything which is in ofono and audio software (pulseaudio)
would need to support thats new API, or users would not be able to use
cellular modem (via ModemManager) and bluetooth at the same time. As two
modem connection softwares cannot be used at one for same time.
This is also reason why I proposed hsphfpd and designed it in this way.
It exports telephony services via DBus API and therefore any telephony /
modem stack software can write its integration parts for hsphpfd and use
it without taking whole bluetooth connection and starts owning it.
So if in future ofono people change their mind, or ModemManager
developers decide that it make sense to add support for bluetooth
devices, they can use hsphfpd API without locking any other software.
One comment here: The hsphfpd should be able to co-exist with
ofono. ofono + PA currently is the only way you can use your mobile
on Linux and we should not break this (unless the hsphfpd supplies
the same functionality). So - similar to ofono - it should at least be
possible to switch off the corresponding role, so that ofono can be
used for one role and hsphfpd for the other.
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
