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

[Georg Chini]

On 18.02.20 11:29, Pali Rohár wrote:
> On Tuesday 18 February 2020 11:06:03 Georg Chini wrote:
>> 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.
> They have important flaws, after they are integrated they completely
> breaks support for headsets which are currently working. This is really
> no-go.
But better to have a starting point than start from scratch.
>
>> 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.
> Me too. But I already spend 3+ months in this area. During implementation
> of hsphfpd and debugging more headsets I saw how they works, what they
> implements and how to use it.
I still can't believe that not implementing all functionality renders
a headset useless. There must be ways to work around such broken
implementations. Would those headsets then not also break with
your hsphfpd if there is no application that handles the telephony
stuff? If not, you obviously found a workaround already.
>
>> 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.
> Disabling headset support means that ofono would not handle bluetooth
> headset. So?
>
>>>>> 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.
> Yes, so then ofono would not handle HFP bluetooth profile.
>
> Therefore you loose support for telephony operations in HFP bluetooth
> profile via ofono. This is obvious.
I don't understand. What you loose are the telephony functions
of the headset like re-dialing and nothing else. The telephone
functionality of a headset cannot be implemented in an audio
server anyway. See also my comments at the bottom.
>
>>>> 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.
> It it used if you want to act as "bluetooth headset". So other
> "pulseaudio" notebooks can connect you to as they would think you are
> "headset". It is not so commonly used.
>
> I already implemented it in hsphfpd and I know how to fix it in
> pulseaudio. For me it is now simple, just I did not wanted to do it
> until all problems with HSP/HFP are resolved.
>
>>>> 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.
> Seems you misunderstood the point. The point is that if you implement
> HFP profile in one application and HSP in second application, then you
> need to implement common functionality on two different places.
>
> So if HSP profile stay implemented in pulseaudio, you would have to
> implement those missing functionality in pulseaudio.
> And if HFP profile is implemented in ofono (or other application) then
> missing functionality must be implemented in that ofono application.
>
> So you would have implementation of e.g. power supply in two different
> locations (for HSP in pulseaudio, for HFP in ofono). And this
> functionality is basically same, so you would have to implement same
> logic on two different places.
>
> If you would need to extend it, you would have to do it again on two
> different places.
>
> In hsphfpd design, I implemented it on one place, in one daemon, which
> shares common functions/code.
All well, but it seems that actually none of the other audio stacks
wants your hsphfpd. So yes, same functionality is unfortunately
implemented in different places. The hsphfpd idea comes far
too late.
>
>> 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.
> Seems you again misunderstood the main problem. Please look at my
> hsphppfd email where I already tried to explain it. Via rfcomm socket
> are handled all functionality of *one* device. I'm taking about one HFP
> device which provides power supply, input event, text display, telephony
> and audio functions. And all this can be handled only by application
> which owns rfcomm socket, application which implements HFP profile.
And where is the problem? We don't need (and can't implement)
telephony functions of a headset in PA. Again, see below.
>
>>> 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.
> I wrote email about hsphfpd to other teams like bluez-alsa or pipewire
> and they can benefit from it. Otherwise they would have to reimplement
> and reimplement whole bluetooth related parts again and again. And
> extending it for new futures...
>
>> Then you can implement things directly in PA.
> But why on the earth you would implement power supply, input event
> handling, text displaying function, phone dialing functionality and
> other things in audio server = pulseaudio?
Why do you insist that we either have to implement all or nothing?
My personal opinion is that we should implement the functionality
that makes sense in the day-to-day usage of a headset. For me this
mainly includes battery status and button press events. In addition
to that we could forward everything that we do not handle ourselves
via D-Bus like your hsphfpd does, but that would already be a bit out
of scope for an audio server. (Maybe something like this could be
an additional module?)

Telephony functionality does definitely not belong into PA, so I hope
you do not misunderstand me. The thing is, that your hsphfpd is a
very good idea but it seems like a lost cause to me because it comes
years too late. On the other hand, I do not want that we just sit back
and do nothing because "it is all too complicated".