Hi Mikel, On 02/22/2013 04:06 AM, Mikel Astiz wrote: > Hi Denis, > > On Wed, Feb 20, 2013 at 6:34 PM, Denis Kenzior wrote: >> Hi Mikel, >> >> >>>> This API is meant specifically for PA or another Audio subsystem. What >>>> you >>>> want to be tracking and cross-referencing I'm not quite sure of. >>> >>> >>> I already mentioned one example: if a headset wants to ignore the >>> inband ringtone, and use it's own custom one, it needs to match the >>> audio-card and the voicecall state. During the ringtone (callsetup=1), >>> the SCO stream would be ignored, as suggested in section 4.13.4 of the >>> spec. >> >> >> Why? Just select a different sound device if the call status is incoming. >> Why do you need to know this down to the lowest level of detail? Or better >> yet, just turn the in-band ringing off at the AG side and be done with it. > > I'm not following any of these proposals. > > For the first one, in order to know the call status, it's necessary to > known the association between the audio-card and the modem. I don't > know what you mean with "lowest level of detail". Just the mapping > between org.ofono.Modem and org.ofono.AudioCard needs to be known, and > ideally, without having to use the modem's serial number. Why? You have an incoming call on Modem A. You know the contact as Contact X. You are ignoring the SCO in-band ring anyway. Just play the 'ring-tone for contact X' until you have an active call. There is no need for you to do any cross-referencing that I see. > > Regarding the second proposal, I'm not aware of this being possible. > Perhaps you can point to some part in the spec where this is defined? > I went back and re-read the spec. I mis-spoke on this one. Indeed only the AG can change this setting, which in practice means it is fully pointless part of the protocol. The fact that HF cannot control in-band ringing setting is a major oversight in the protocol in my opinion. >> >> The AG can start an audio connection for any reason whatsoever, trying to >> 'outsmart' it will likely never work due to deficiencies in the protocol. I >> would love to hear how you plan to implement voice recognition policies. > > The AG reports when voice recognition is active, so I see no big deal > with this one. > Yes it does. My point here was that you still do not need any cross-referencing here. Just pipe the data to SCO when it is asked for. >>> >>> I could list more examples too if needed, but they would involve >>> multiple connected AGs. >> >> >> Please do. > > Examples include two connected AGs (phone A and phone B) where one of > them (A) contains an active call, and the other one (B) contains a > held call. In this case the audio from phone A should be routed, and > the one from phone B ignored. > > This one is very similar to the first example: the audio-subsystem > needs to know the call status associated to each audio-card. > So we're off into advanced use-cases lala land, where we have multiple SCO streams, have you even tested whether multiple simultaneous mSBC streams work? And how do you even get to this point? If phone A is on the call and you get a call on Phone B, what do you even do? Auto-hold Phone A? Play Ring Tone while Phone A is active? More importantly, why would you keep both SCO links active in the first place? Actually, I'm not sure I want to know ;) Right now we don't even have the simple 1:1 connection case working properly, so lets get that working first before running off into the weeds. >> >> >>> Not that I agree with the idea of re-engineering the Media API, but >>> anyway... >>> >> >> Lets put it this way, Media API has a snowball's chance in hell of going to >> oFono upstream. So lets put this discussion to rest already. > > You're certainly aware that this duplicates the client code since they > have to have separate implementations for A2DP and HSP/HFP. The motto > of "simplifying client code" is not relevant anymore, as it seems. > I disagree completely. Media API was trying to abstract both protocols which are completely different. It didn't do a very good job, whatever was being encapsulated still bled through into the API, particularly things oFono would never ever care about. In short, the oFono side of things looked just plain awful. By the way, whatever points you are raising above, would still apply to the Media API, you just have to deal with even more complexity. In the end I rather have more code that is simpler to understand than less code that is unreadable. Regards, -Denis