On 18.02.20 10:34, Pali Rohár wrote:
Hello!
On Tuesday 18 February 2020 09:42:38 Georg Chini wrote:
On 15.02.20 22:33, Pali Rohár wrote:
Hello!
More then two months ago I started discussion how to handle currently
unsupported parts of Bluetooth HSP and HFP profiles on Linux via
pulseaudio.
Main problems are:
1) These profiles are bound with telephony stack and without having half
of telephony stack it is not possible to handle stable and working
HFP profile. Telephony stack is needed for parsing AT commands and
handling state machine.
There are several patch sets on gitlab and on the mailing list that
prove that you don't need half the telephony stack. Yes, you need
some of it but I think you overestimate what is really needed.
These patches does not work and completely break support for some
headsets which are currently working fine. Examples of such headsets are
from Creative Labs company. I already wrote it to pull request on
gitlab.
So no, this is not a solution, breaking support for headsets which are
currently working fine.
They are at least nearly working. Yes, they have some flaws
but with some work on them it can surely be improved. Work
on the implementation is needed anyway and the old patches
on patchwork and the current ones on gitlab provide a good
starting point because a lot of the work is already done.
2) Only one application can own RFCOMM socket over which are transmitting
AT commands.
3) Application which own socket needs to implement all features of HSP
and HFP profiles. Therefore if users want to read battery status,
this application needs to implement it. If users want to handle
headset buttons, this application needs to implement it. And if users
want to do telephony operations, this application needs to implement
whole telephony stack.
Again I don't agree. There is no need to handle the whole telephony
stack if you only want headset support.
Unfortunately for some headsets it is needed :-(
I can't believe that. Maybe you have to supply some dummy answers
to certain AT commands, but it should be doable.
4) Wideband audio depends on HFP profile. Therefor 3), 2) and 1) must be
solved if we want wideband high quality audio support for voice
calls.
To solve these problems I proposed a new hsphfpd daemon which would
implement HSP and HFP profiles, therefore a new daemon which would own
rfcomm socket and would proxies AT commands (which could not resolve by
its own) to target applications. So telephony operations could be
implemented by one software (e.g. ofono), battery/power related by
another (e.g. upower) and audio by another (e.g. pulseaudio).
This design was rejected by ofono developers as they do not want to use
such proxy daemon. ofono already implements some parts of HFP profile
(but not HSP) and therefore is in the position of the "owner" of rfcomm
socket, like my design of hsphfpd. ofono already provides some API for
audio applications, but this API is not very suitable. I asked about
missing features and APIs which are designed and provided by hsphfpd,
but after a longer discussion ofono developer said that there are no
plans in ofono to implement missing features and APIs of HFP profile
which are currently missing in ofono. Also ofono's implementation of HFP
profile requires in computer to have connected and working cellular
modem, without it bluetooth HFP profile for bluetooth headsets does not
work. Pulseaudio has on wiki written some steps how to workaround this
limitation by usage of modem simulator, but ofono developers wrote that
this is hack and should not be used at all. And HSP profile is not
supported at all.
So conclusion from ofono discussion is: They do not want to support my
proposed solution via hsphpfd. And also they do not plan to implement
missing features of HFP profile to their HFP implementations, like usage
of bluetooth headset without connected cellular modem into computers,
support for HSP profile, support for custom HSP and HFP audio codecs,
support for battery and input buttons, etc...
So ofono is fully unusable for any HSP or HFP features of bluetooth
headsets on regular desktop or laptop computer with Linux.
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.
This is not true. You can disable the ofono headset support selectively
in ofono, so ofono could still handle telephony while PA handles headsets.
Ok, so if this is truth that you can disable ofono <--> bluetooth
support then you can still use your cellular modem to work with ofono
(which is great!), but obviously you loose telephony support on HFP
bluetooth profile. And therefore without telephony support on HFP you
cannot use HFP nor HFP audio. So problem is still there, but it allows
you to have started both ofono and other tool which would implement
telephony stack for HFP.
You misunderstand me. You can selectively disable headset
support in ofono while keeping the other role fully functional.
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 as you can see there is no reasonable solution. Bluetooth rfcomm
socket would be owned either by ofono (and then there would be no
support for computers without cellular modem) or by other application
e.g. pulseaudio, hsphfpd, ... (and then ofono needs to be stopped and
telephony functions would not be probably supported in near future).
Well, the reasonable solution is to implement HFP headset support
in PA and let ofono do the telephony bits.
This is only possible with cooperation with ofono as application owns
rfcom bluetooth socket must (currently ofono) must export all needed
APIs for other application. But ofono developers said that this is not
currently planned.
Yes, it is really reasonable solution, but it is not possible right now.
As said above, you can simply disable headset support. You
just have to specify --noplugin=hfp_ag_bluez5 on the ofono
command line.
HSP is already handled
in PA and ofono does not implement it, so I see no issue there.
Issue is that PA's implementation does not support additional features
(like custom codecs or event buttons or power status). And AG role is
broken (there is broken implementation of handling master listening
bluetooth socket).
Since when is the HSP AG role broken? It worked (at least for me)
about two years ago. And support for additional features
can be added. It must be done anyway somewhere, whichever
solution you want to implement.
In addition to pure audio, PA can handle headset related features
like battery status, button press and display messages.
Yes, this is possible, but these custom features are same in HSP an HFP
profiles. It means you would need to implement them on two different
places (where would be handled HSP profile and where HFP). And I do not
like this solution.
I don't think this is true. The additional features are handled via
the RFCOMM channel and that channel is the same in both cases.
Because HSP is a subset of HFP, you can use the same RFCOMM
handling, in the worst case with a flag to distinguish between HSP
and HFP.
And now I would like to hear from you, pulseaudio developers/maintainers,
which option 1) - 5) you choose to solve problem with Bluetooth HSP and
HFP profiles, specially for wide band support, battery level support,
input event support, telephony support and etc.. So features which are
provided and supported by now all common Bluetooth headsets.
I'm willing to implement option 2). I have already implemented prototype
implementation of hsphfpd and it is already working. So missing part is
support from pulseaudio side. I can implement it and push pulseaudio
code via pull request or patch to mailing list. For pulseaudio it means
implementing just audio parts of HSP nad HFP profiles. Not telephony or
battery/power functions. If somebody is interesting in this option, help
me with this (either pulseaudio part of hsphfpd daemon itself), please
let me know.
On other options 1), 3), 4) or 5) I'm going to participate as I do not
think they bring any value to Linux desktop. And just cause another
problems.
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.
Please note that this is not problem only for pulseaudio, but also for
any other audio software which want to support HSP/HFP on Linux.
Overall I think the problem is not so big as you describe it.
I do not see an issue in the co-existence of ofono for telephony
and PA for headsets. In PA, we only need to implement those
additional features which are commonly used. Yes, we will not
be able (and will not want) to support everything but is that really
a problem?
I think you do not see the main problem. You cannot do telephony
functions in one application and audio related in another and
power/button/display in another. Only application which own rfcomm
bluetooth socket can do these operations and therefore one application.
The RFCOMM channel is created when the profile is connected,
so it should be possible to have one RFCOMM to device A in AG role
and another one to device B in HS role and have ofono handle one
device while PA handles the other.
And you cannot share rfcom socket to more applications as it is
stateful. So what you wrote is not possible to implement. So this is a
big problem.
To allow splitting functionality between more applications I designed
hsphfpd daemon which acts like proxy for rfcomm bluetooth socket and
export needed functionality via DBus APIs to more applications, like you
described above. Please look at my email about hsphfpd where I written
more details about it.
Yes, but it does not make sense to implement hsphfpd only for PA.
Then you can implement things directly in PA.
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
