Hi Denis! On Wednesday 18 December 2019 19:03:12 Denis Kenzior wrote: > Hi Pali, > > > Yes, I see. Also there are devices without HFP support, only with HSP. > > pulseaudio support also these devices and pulseaudio is not going to > > drop support for them. Last time when I looked at ofono, it has no HSP > > support. Is ofono going to add support for HSP? > > > > No. So your answer means that we cannot use ofono at all and therefore we need another daemon (like my proposed hsphfpd). > <snip> > > > > > But would you accept patches which exports DBus API e.g. for displaying text > > on HFP headset with embedded display? Or patches which implements 3 > > different way for reporting battery level status of HFP headset? And API > > for sending "computer battery level" to HFP headset? Or implementing > > setup of SCO sockets (via RFCOMM layer) for custom codecs? Or exporting > > uinput linux device for button press events? Because all these > > So which roles are we talking about here? Your Design document shows > hsphfpd registering for both HFP AG and HFP HF roles, but maybe this was not > the intent? My proposed hsphfpd is going to support both roles. Which means to implement whole HFP profile. So for connecting bluetooth headsets (when AG role is needed on desktop) and also for connecting mobile phones (when HF role is needed on desktop). And my primary motivation is for bluetooth headsets as this is what are asking desktop and laptop users again and again that is missing on Linux systems. So higher priority has AG role and slightly lower priority has HF role. > If you're talking about extending oFono APIs when it is acting as the HF > connecting to the AG, then codec setup APIs, etc are definitely something > that would be welcome. > > If you're talking about AG role, then that is different... In general, if > the oFono is in an AG role, then there should be nothing to configure and > there are no APIs for this role. Codecs needs to be configured also in AG role. Before accepting SCO connection you need to configure SCO socket for correct codec. Also for vendor codecs it needs to be properly negotiated via AT commands. > Things like reporting AG battery level to > HFP headset are done directly using plugins. See > ofono_emulator_set_indicator and how this is done by upower.c for example. > I happily take patches for any additional features (codecs, etc) you want to > support here. > > But... oFono upstream has no interest in accepting forwarded AT commands > from some external daemon if we're in AG role. We rejected such a design > years ago and nothing has changed. > > AG role is already quite tricky to implement without additional complexity > introduced by having multiple applications and IPC. "Its your funeral" as > the saying goes if you want to go that route. I know that it is not so easy to implement --- I already created prototype implementation and proposed API how to do it. But > <snip> > > > I disagree here. Primary purpose of HFP for desktop users is ability to > > use bluetooth's microphone. And not telephony stack and its complicated > > features like call hold and others, which are in HFP used and > > implemented probably only in car kits. > > So your primary goal here is to have the desktop play the role of the AG, > purely so you can forward the audio from a headset out to whatever it is > that you want. And you want oFono (or some other daemon) to (optionally) > handle the call related AT commands in the HFP AG role. Yes. Exactly. > Such a design will get a NAK from me on the oFono side. But don't let that > stop you. You can simply invoke oFono APIs directly from your daemon. No > need for any changes in oFono itself. As mentioned above, I wouldn't > recommend it, but... :) So if you are disagreeing with this design, can you propose alternative? Which would support needs for desktop users? Support for HSP profile (in AG role), support for HFP profile (in AG role), ability to parse and interpret needed AT commands. And later also HS and HF role of these profiles. > > > > > > > Also for using ofono with HFP profile is not possible on desktop > > > > > computer which do not have any modem as it is hooked to some active > > > > > modem. > > > > > > This statement is not true at all. You can use oFono without any 'real' > > > modems attached. It can happily manage only HFP devices (or modems as we > > > call them.) > > > > Ok, can you please provide exact steps how to do it, including > > activating of bidirectional audio stream? > > So again, which role? If we're the HF connecting to the AG, then things > just work without a modem. If we're the AG, then yes you need a modem to be > driven by the AG connection. AG. > > > > > > You must be thinking of the oFono HFP AG implementation... > > > > Yes! For connecting bluetooth headset you need HFP AG implementation. > > > > And I guess this is the reason why simulator is needed. HFP headset acts > > as a "client" for modem. Therefore on desktop / laptop you need to > > implement "modem server" which will be used by HFP headset "client". > > > > And phone simulator is doing exactly this "modem server", it is > > simulator of modem. > > > > Okay, I see now. Yes, the above is correct. My comments about not needing > a modem device hold true only if oFono is in HFP HF role connecting to an > AG. Ok. So I guess now you understood main problem. I thought it was obvious, but seems that bluetooth HFP is too complicated, so talking about it always needs more detailed explanation. Sorry for that if it was not clear from my side since beginning what are requirements for my setup. And question now is how to solve this problem for desktop computers? Users who want to use their bluetooth headset (HF role on headset; AG role on laptop) really do not want to do complicated setup of modem simulator just to use microphone input from headset. This is reason why I'm proposing hsphfpd daemon and with its API to work without any modem emulator or ofono software (but optionally modem could be connected). -- Pali Rohár pali.rohar@xxxxxxxxx
Attachment:
signature.asc
Description: PGP signature
