W3C home > Mailing lists > Public > public-audio@w3.org > April to June 2012

Re: Exclusive access to audio hardware

From: Jer Noble <jer.noble@apple.com>
Date: Wed, 09 May 2012 17:07:42 -0700
Cc: robert@ocallahan.org, "public-audio@w3.org" <public-audio@w3.org>
Message-id: <72D8FAA1-7728-4867-8A9D-6D8B078C7364@apple.com>
To: Chris Rogers <crogers@google.com>

On May 9, 2012, at 3:55 PM, Chris Rogers <crogers@google.com> wrote:

> On Wed, May 9, 2012 at 3:32 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
> I think it would be simpler for authors if everything "just worked" as far as possible. With the proposed renderState and onrenderstatechange, some developers are likely to simply forget to handle it --- if the renderState is never idle on their platform or they simply don't test that case --- and their apps will be broken.
> 
> So how about adding no new APIs, but instead just automatically pause the entire audio graph while the page does not have access to the audio hardware?
> 
> I could be wrong, but I think Jer is saying that the graph *would* be automatically paused.  It's the restarting/resuming that Jer would like authors to have the opportunity to control instead of it automatically starting to play the instant the phone call ends.

Yes, exactly.

On May 9, 2012, at 4:11 PM, Robert O'Callahan <robert@ocallahan.org> wrote:

> OK. That isn't very different from in-app pause-and-resume to handle different modes which happen to be in the same app, for which game devs have already asked for pause and resume API, and which I think we should provide (preferably per-node/stream but could be per-context). Also, developers who want to extend the pause after other activity ends should opt into that; the default needs to be automatic resume, so that apps don't get stuck.
> 
> So I suggest providing API for explicit pause and resume, and define its interaction with UA-imposed pausing so that the graph is paused if it has been paused by the author *or* it has been paused by the UA. Then an author who wants to wait for some interaction before resuming can pause explicitly, say when their app loses focus, and resume explicitly whenever they want to.

That makes a lot of sense.

So, with that in mind, here's a new proposal:

interface AudioSession {
...
// Play state flags
const unsigned short PLAYING = 0;
const unsigned short INTERRUPTED = 1;
const unsigned short PAUSED = 2;
readonly attribute playState;

void play();
void pause();
...
}

An AudioSession would start in the PLAYING state.  An audio hardware interruption would move the state from PLAYING to INTERRUPTED.  Once the interruption ended, the state would move from INTERRUPTED to PAUSED.

When the state is PLAYING, pause() would move the state from PLAYING to PAUSED.  When the state is PAUSED, calling play() would move the state from PAUSED to PLAYING.  If the audio hardware is unavailable, the state would move from PLAYING to INTERRUPTED.

When the state is INTERRUPTED, both play() and pause() are no-ops.

-Jer
Received on Thursday, 10 May 2012 00:08:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 10 May 2012 00:08:14 GMT