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.
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.
If you want to control everything down to the nitty gritty, you probably
need a dedicated application. There's no way all of this level of
detail is ever going to be exposed over IPC. Even oFono core lacks much
of this information due to abstractions.
I could list more examples too if needed, but they would involve
multiple connected AGs.
Please do.
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.
The ability to distinguish HS and AG roles in the client's side is
desirable (at least PulseAudio heavily depends on this information).
So even if the proposal above is not accepted, at least the role
(UUID) would have to be exposed somehow.
The type information was left out on purpose from this proposal. Likely it
is necessary, but for the initial phase it does not seem relevant. I also
have yet to hear concise and clear summary on the utility of providing this
information.
I can summarize PulseAudio's case. The current policies slightly
differ in the way SCO is handled. The HS role is more passive,
accepting remote SCO connections and releases. The AG, on the other
hand, initiates an SCO connection as soon as some audio starts
streaming, or the user sets the card's profile to "hsp" manually.
The HS role currently switches between HSP/HFP and A2DP automatically.
So if SCO starts streaming, the profile is switched and the audio gets
routed. This is not the case for the AG role (desktop use-case) where
no automatic switch exists and the user-setting applies. I believe
this shouldn't be necessary in the long term, if the routing problem
was solved, but that alone is a big topic.
Finally, PA exposes per-profile information in the UI, so the user
actually distinguishes AG and HS roles. So if you pair a Nokia support
both profiles, you would see them both in the UI. I guess this could
be changed, but not without a controversial discussion. Even several
BlueZ developers have argued that this information is very convenient
for development and testing.
Note that the HSP vs HFP difference is not relevant, so I'm just
talking about separating AG vs HS roles.
I'm still lost. But that is okay. Can we please implement the basic
proposal as it is now and then start adding features? Remember the
motto, 'make it work, then make it work better'.
If so, I have some concerns about the potential race conditions. If
SCO was closed and reopen immediately afterwards, the client could
receive the (second) NewConnection before the HUP.
You are going over-the-air vs local machine. I really do not see this ever
happening. But even if it does, is this really a hard problem for the Agent
to deal with?
I think it would be quite obscure to assume that the previous socket
will HUP shortly after this second NewConnection is received. So if
this approach is encouraged, I'd expect some reference in the doc.
Uhhh, this situation will never happen. Too much thinking, stop it ;)
If you want to be ultra-paranoid just close the previous socket when you
get a NewConnection with the same card id, but I digress...
Regards,
-Denis
_______________________________________________
ofono mailing list
[email protected]
http://lists.ofono.org/listinfo/ofono
