Hi Denis! On Thursday 19 December 2019 08:53:54 Denis Kenzior wrote: > Hi Pali, > > > > > 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. > > > > So to summarize. You have broadly 3 main use cases for HFP: > > 1. HF connecting to AG role. Essentially a carkit role. oFono does this > pretty well already and has the APIs defined that cover up to HFP 1.7. Any > vendor extensions can be easily added. And some carkit manufacturers > already use it. > > 2. AG role when you have a 'real modem' behind it. oFono already provides > everything needed for this scenario. > > 3. AG role when you don't have a real modem or you have some sort of VoIP > use case. oFono doesn't cover this case as you stated. In your list are missing another two use cases: 4. AG role without real modem connecting yo HS role in HSP profile 5. HS role connecting to AG role in HSP profile 3. and 4. is my primary focus which is the most common scenario for desktop / laptop users with bluetooth headset. 5., 2. and 1. are also covered in hsphfpd design, but with lower priority (implemented after 3. and 4. is fully working). 3. and 4. would share some part of code, specially handling of battery status parsing via CSR and Apple extensions or CSR codec selection. What do you suggest for 4. and 5.? > So I can see value in something that implements case #3. But having said > that, oFono will not be receiving AT commands from external daemons: > - For case 1, it'd just be a rehash of what oFono does well already. I > reinvented a few wheels in my time, but doesn't mean I think this one should > be. > - The reasoning for case 2/3 I already covered upthread. > > > > 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. > > > > Sure, but that doesn't mean they need an actual D-Bus API to be configured > with. You can simply extend oFono emulator to support whatever codecs you > want and whatever custom AT command handling that you need. If the HF > requests the codec, then you use it. There's no D-Bus API required here. > Again, take a look at how this is done in oFono today. > > > > 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. > > > > There have been one or two implementations of AG role fully external to > oFono. These implementations simply used the existing oFono APIs to drive > the modem. bluez & pulseaudio developers told me that it would be a good idea to avoid implementing a new AT parser for telephony stack. And rather use ofono implementation for telephony part... But if I should use existing DBus API provided by ofono, it means that I need to do parsing of all AT commands (including telephony) and translate them to ofono DBus API. I agree, this should work and there is not need to modify ofono. But it means that in hsphfpd daemon I need to have full AT parser for all telephony commands and it was something which bluez / pa developers thought that should be avoided. Therefore I come up with idea that telephony commands would be handled by external Telephony Agent, which can be ofono. > You could do that. But as I said, we rejected such a design a > long time ago due to complexity and other issues. Anyway, what is the problem with accepting modem socket in ofono via DBus and starts talking with it like with any other modem which ofono supports? Currently ofono already takes modem socket from bluez via DBus API, so in same way hsphfpd can pass modem socket to ofono. Basically ofono then can reuse same code which already uses for sockets from bluez, just it do not have to parse and interpret audio related AT commands (as these are handled by hsphpfd itself). What are exact issues? I do not see complexity at ofono part (as has already everything implemented) and currently I do not see those "other" issues. > Or you can ignore the call control aspects entirely... > > But in the end, it is your architecture. All I can do is point out (early > in the process) what is and what is not acceptable to oFono upstream. And this is why I started discussion across all projects (pulseaudio, bluez, ofono) so describe current problem and come up with some architecture which would be suitable for all projects. So thanks for all your points. You suggested to use phone simulator together with ofono and then starts extending / patching phone simulator to supports all needed parts which are in my hsphfpd design (battery status, button press, codec selection)? Also how to handle the main problem of phone simulator that it is too much complicated to setup it on desktop? Looking at the steps... https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Bluetooth/#index5h2 ... that desktop user needs to run nontrivial commands in command like, plus creating configuration file only just to connect bluetooth headset is ridiculous and non-acceptable for desktop application. If this problem is not fixed, ofono and phone simulator are not usable as "main" software implementation of HFP profile for usage of bluetooth headsets on Linux. > > > > > > 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. > > Well it was a bit of reading comprehension fail on my part as well. The two > roles are really quite different, so precise language helps. > > Regards, > -Denis -- 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
