On Friday 20 December 2019 23:46:57 Pali Rohár wrote: > Hi! > > On Friday 20 December 2019 15:19:01 Denis Kenzior wrote: > > Hi Pali, > > > > > > 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... > > > > In my opinion there's nothing scary about AT parsing. In fact that is the > > easiest part of this whole venture. If you don't want to roll your own > > parser, you can borrow one from the oFono project. We already solved this > > nicely in the form of the gatchat library. You could incorporate this into > > your project (if it is GPL compatible). Or you could wait until we port > > gatchat to ell which will be under LGPL license. > > > > > > > > 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 think you will need to do this regardless. Otherwise I fail to see how > > you prevent one 'agent' from consuming AT commands it shouldn't be. This is > > a possibility you need to consider, whether it happens by accident or > > maliciously. > > Some subset of AT commands are needed to parse and interpret. But not > telephony commands and having up-to-date internal telephony state. > > > > > > > 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. > > > > Understood. But I think the metric function was selected inappropriately in > > this case. My opinion is that you should have started with what the overall > > architecture should look like; you should not have based design decisions on > > which parts might be a little hard to implement. > > > > > > > > > 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. > > > > The issues are many. And really the question is not whether it 'could be' > > done, but whether it 'should be' done. Let me describe a couple examples: > > > > - In the case of HF role (1), oFono already provides all the necessary APIs. > > So put yourself in oFono's maintainer shoes. What would we gain by > > supporting almost the same but different mechanism? We would have to > > introduce a new hfp_hf plugin, one that is almost identical, but different > > to hfp_hf_bluez5 plugin. > > Yes, this would be needed, but because code os very similar it could be > reused from one common place. > > > These two plugins would have coexistence issues, > > which would add more complexity. Then there's the impact on PulseAudio and > > other users. How do they know when to use the HandsfreeAudio API vs some > > external API? > > Because pulseaudio has already own implementation of HSP profile and > some kind of ofono implementation (which you named below "giant hack") > it already needs to handle such problem. > > But solution should be relatively simple. If we decide that new daemon > is "new proper way" then it would have higher priority as current HFP > API by ofono. So if hsphfpd is registered on dbus && hsphfpd say that it > is active, then use hsphfpd. Otherwise if ofono is registered on dbus > and say that device is active/connected use ofono. > > > Supporting this new way buys us a lot of extra code / > > complexity with no value added. > > Value is support for HSP profile and support for HFP AG role without > modem. And it would provide (for PA) unified same interface as for HFP > HF role and HFP AG role with modem. I think this is a big value for PA > (or bluez alsa or pipewire) to have one API which would handle all HSP > and HFP profile/role combinations. > > > - The other example is more practical. HFP Service Level Connection (SLC) > > establishment is actually quite tricky. There are certain limitations on > > what can and cannot be done prior to SLC establishment, including how audio > > handling is done. > > I know :-) I already implemented prototype implementation to check and > see how complicated it is and if API make sense and how hard it is for > agents (audio - pulseaudio) implement and maintain it. > > > Unfortunately, codec negotiation, indicator negotiation, > > and feature negotiation are part of the SLC. oFono already solves all of > > this and handles all of it nicely. > > CSR codecs are not supported nor implemented in ofono. It is more > complicated as HFP codecs... and needs a new API for audio application. > Another value which brings my hsphfpd is that it handles these CSR > codecs and provide API for audio application to use them. > > > We have passed all relevant > > certification testing. It is very unclear how you plan to handle this (or > > whether you realistically even can) in your architecture when the > > responsibilities are split between the various daemons. So again, oFono has > > nothing to gain here... > > I was not thinking about certification. It is not something which I > could do.... And also pulseaudio itself do not have certifications. > > > > > > > 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)? > > > > > > > Not quite. I suggested you expand oFono's emulator implementation (for AG > > role) and its DBus APIs (for HF role) to support the new vendor specific > > features that you want. > > > > Forget about the phone simulator, it is really irrelevant for what you're > > trying to accomplish. > > Ok. I thought that phone simulator = ofono emulator. I just saw that > phone simulator which is described in pulseaudio documentation. > > > > 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. > > > > oFono was never advertised as solving the 'HFP AG without a modem' use case. > > This is something we never had as a requirement / objective. Phonesim is a > > development tool. So of course it isn't trivial to setup, it isn't meant to > > be used in production in the first place. The use of phonesim described in > > the PA wiki, while creative, is a giant hack ;) > > Ok, so we definitely agree that ofono currently do not support HFP AG > without modem for desktop users. And this scenario is needed for > connecting bluetooth headsets, so we need some solution for it. > > > Basically it all boils down to the fact that nobody has stepped up all this > > time to solve a particular use case you care about. But blaming oFono for > > this is misguided. > > > > So, if you want to solve the HFP AG without a modem case I fully support > > your efforts. > > Ok! So which options do we have? > > > Perhaps this can even be solved in oFono itself (since it already does 90% > > of what you want) by making the modem requirement optional. What we could > > do for example is to create a dummy modem if an AG connection is requested > > and no other suitable modems are detected in the system. The resultant AG > > wouldn't have any call control capability, it could still be used for > > transferring audio data, battery, etc. If you want to pursue this, we can > > brainstorm further. > > Well, if this would work automatically without any user interaction or > without special setup, it seems to be usable. > > But what is needed from this implementation in ofono? Basically API for > each functionality designed in hsphfod daemon. And one of it is also > support for HSP profile (with CSR and Apple extensions). > > I'm not against for it, but I thought that having functionality which is > not related to telephony / modem you would not want to see in ofono > project (like linux uinput layer for button events or API for displaying > raw text on embedded display; or CSR audio codec negotiation). > > So how do you see possibility to have also HSP profile in ofono? So have > one place which would provide audio API for SCO? Because this is a big > requirements from audio software side, to not use 4 different APIs to > access SCO sockets (and its rfcomm / SLC configuration) in HSP and HFP > profiles. Hi Denis! Can you look at this email? I would like to know what could be next steps, specially if ofono (in some way) could be extended for all use-cases and would be usable for Linux desktop. Or not and I rather should continue with my hsphfpd proposal. -- 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
