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. 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. 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. 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). 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. -- Pali Rohár pali.rohar@xxxxxxxxx
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
