Re: Telephony API draft updated

On Fri, Nov 30, 2012 at 7:44 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> Even after that long email, of course I forgot to mention a few things :-)

Both happen to me too, long emails and *still* forgetting to mention things.
I bet people would prefer me forget even more things, rather than
writing even longer emails :).

>
> The first one is that just because the implementation of the API might
> not have a backend to talk to until there is a call connected, doesn't
> mean that we couldn't create an API which allows setting the volume
> anytime. The API would simply have to take over the logic of tracking
> if there's a call connected and if there isn't, remember the stored
> values until a call is connected.

Yes, we discussed this in the last email, it's a kludge, but does not
seem impossible to do, and I've seen worse things in telephony.

>
> The second point is that I'm not convinced that the telephony API
> should contain audio controls at all.

Finally. I fully agree.

> In Firefox OS we've recently
> started working on a Audio API which we've needed to manage various
> non-telephony related audio channels. This API deals with things like
> muting currently playing music when the alarm clock goes off. And
> allowing UI audio volume to be separated from the volume of "incoming
> SMS" and "incoming Email" notification sounds.

I know this area through a few products, and it can really be a mess :).

>
> Our goal is to allow this API to also modify the audio channels
> that
> are used by a telephony application which is built on WebRTC. I.e. if
> you receive an incoming WebRTC call, you'll want the same type of
> audio controls as we've been talking about for the telephony API.

Yes, exactly.

> However I don't think it would be correct to let a WebRTC-based
> application use the telephony API to control audio volumes.

Correct.

> If nothing
> else it would create a much more complex security model since of
> course the WebRTC-based application shouldn't have access to the
> telephony hardware.

Why should it access the telephony HW?
For setting volume on WebRTC we could use a similar MediaControl
object I drafted in the last email, but which would be connected by
the implementation to a different backend.

>
> The API is still in early stages and I wouldn't recommend removing the
> audio features on the Telephony API for now since we don't yet have a
> full replacement. But I think it's something that we should keep in
> mind as we're talking about audio features for telephony.
>
> Here is what the API looks like so far:
>
> https://wiki.mozilla.org/WebAPI/AudioChannels

What you seem to be doing there is
- correctly identified some mobile use cases
- suggested a solution which looks simple to spec an API for,
cooperative audio policy management among applications, and using some
patterns like wake-up locks (similar to what Android uses).
The cooperative application-level policy management proved to be a
fundamentally broken idea in the past I have seen.

A better approach would be to let device makers specify their audio
policy (which can be wildly different case by case), implement a
central policy decision with distributed enforcement, and define an
API for apps so that they can request what they would like to do - but
which may be overridden by the system, in which case the app should be
notified about it.
Also, notifications should be handled in relation with this, e.g. when
there is an incoming call, depending on the policy, the profile, and
the user settings, the phone may beep, vibrate, flash the screen, ring
a generic tone, ring a contact-specific tone, etc.
Or, should phone calls be notified during camera recording (and if
yes, how). Or, if and how map navigation happens during a phone call.
Or, how alarms are handled during a call (and depending on which audio
route is active). And all stacked combinations of the above. Locks
cannot handle that in a generic way, you'll see races, livelocks and
deadlocks in a short blink.

This is a bit off topic, but no wonder we ended up discussing it,
since all dialer developers will face these issues. So we should
monitor/discuss also the related API developments.
I wonder how is it supposed to happen in this work group.

Best regards,
Zoltan

Received on Friday, 30 November 2012 10:09:05 UTC