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. 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. 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. 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. Regarding the lack of time to discuss: I'm sorry it took this long to get any input from me. Just staying up to date with everything happening on GitLab, various mailing lists and IRC has taken almost all my time. I have now decided to try allocating 20% of my PulseAudio time for working on your bluetooth stuff. Georg has been in a similar situation as you, so I'll give Georg another 20%, and even though getting the 14.0 release out is supposed to be the highest priority thing, that work hasn't progressed much lately either, so another 20% goes there. Probably the end result is that I won't be able to keep up with the GitLab messages any more, but it's worth trying... [1] I've had to read the oFono discussion on the linux-bluetooth mailing list, because your messages don't get through to the oFono mailing list. Please subscribe to the list if you haven't done so yet (and trim the Cc list, the messages get blocked due to that too), they don't seem pay attention to the mailing list moderation queue. -- Tanu https://www.patreon.com/tanuk https://liberapay.com/tanuk _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
