On Tuesday 07 January 2020 11:35:48 Denis Kenzior wrote: > Hi Pali, > > <snip> > > > > 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. > > Please think some more about what I said. You will need to parse every AT > command in your daemon, no way around that. You are right that you do not > need to keep track of the telephony state, but that is besides the point. > So if you need an AT parser anyway, the whole reasoning for the proposed > architecture starts to look shaky. I do not need to parse and interpret all AT commands. Telephony commands does not have to parsed and interpreted. They can be forwarded to telephony agent (if connected) OR replied with ERROR as a result that command is not supported. > > > > > > - 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. > > > > Again, you're not addressing my main point. Codec negotiation is part of > SLC establishment. SLC has both telephony and audio aspects. They're > inseparable. Your architecture fails to address this... Why? Codec negotiation is part of SLC, but codec can be changed prior opening SCO connection. How my architecture failed? What to address? I implemented it in my prototype and it is working. So I do not understand your point. > CSR codecs are not part of SLC and can be bolted on later. I already told > you that oFono can easily be changed to support this. I'm not disagreeing with this. > > > 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. > > So again, no reason for us to get involved :) > > Bottom line is there's no value for us in this architecture. If you want to > use the existing oFono APIs, that's fine. But we're not adding a plugin for > taking arbitrary AT commands from some other daemon :) I can say exactly same. I'm not interested in any certification, I do not see reason to care about it. Pulseaudio does not have any and is the de-facto standard way how to use bluetooth audio on Linux. > > > 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). > > Start a separate thread on ofono for this. I already gave you hints on how > to solve the 'AG without a real modem' use case. That would seem to be the > biggest 'win' and it should be fairly easy to make this work. Ok, I will start a separate thread. > > > > 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. > > > > HSP is a separate issue. It is not separate issue. It is one of the main issues. If ofono is not going to support HSP then there is absolutely no reason why to use ofono and extend it to support a new features which currently do not support (like CSR codecs which are in both HSP and HFP profiles). Basically without it ofono is unusable for handling bluetooth audio on Linux desktop. > Maybe we can handle it like the 'dundee' daemon > inside oFono (which handles Bluetooth DUN profile). In other words have a > dedicated daemon for hsp support that reuses the relevant bits of oFono and > maybe exposes the same APIs (i.e the ones documented in > doc/handsfree-audio-api.txt). That would make life for PulseAudio pretty > easy. > > Regards, > -Denis -- Pali Rohár pali.rohar@xxxxxxxxx
Attachment:
signature.asc
Description: PGP signature
