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

[Georg Chini]

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.