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. > 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... Ok. > [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. I do not want to subscribe to other mailing lists as I do not have a time to receive another tons of emails and decide what should I read and what immediately drop. And because I'm not planning to read and discuss about ofono details, I did not subscribe to that list. Basically I CCed people and other mailing lists which should be interested in it (or wanted from me to be in loop). -- Pali Rohár pali.rohar@xxxxxxxxx _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
