W3C home > Mailing lists > Public > public-audio@w3.org > January to March 2012

Re: ISSUE-5: pausing a subgraph

From: Robert O'Callahan <robert@ocallahan.org>
Date: Mon, 26 Mar 2012 16:36:43 +1300
Message-ID: <CAOp6jLZMU+E+k8KvcmPMEmTTyNw9U9CihnRnctNW_3rrYY_7yA@mail.gmail.com>
To: Alistair MacDonald <al@signedon.com>
Cc: Chris Rogers <crogers@google.com>, olivier Thereaux <olivier.thereaux@bbc.co.uk>, public-audio@w3.org, jussi.kalliokoski@gmail.com
On Fri, Mar 23, 2012 at 4:27 PM, Alistair MacDonald <al@signedon.com> wrote:

> Forgive me if I'm being a bit dense; I'm having trouble trying to think of
> why pausing the sub-graph would be useful. I have zero experience writing
> software to mux discontinuous streams, so I may be missing something
> obvious.
> What is the actual benefit of being able to pause the sub-graph?

Jussi's probably the best person to answer this, since the request traces
back to him.

But I can make up an example. Suppose I have a desktop environment with a
set of widgets on the screen, where each widget's audio stream is
spatialized to sound like it's coming from the widget's position on the
screen. Now suppose I have a media player widget that uses an internal
audio graph. It would make sense to offer a "pause" API for that widget (or
maybe all apps); that API would want Chris' behavior 1a.

That may be a bit far-fetched. Maybe there are less far-fetched use-cases;
maybe there aren't. The example of a game that pauses to switch to a menu
with its own sounds is close, but it can be handled with multiple
independent audio graphs since the menu and the game never need to be mixed
together with effects.

“You have heard that it was said, ‘Love your neighbor and hate your enemy.’
But I tell you, love your enemies and pray for those who persecute you,
that you may be children of your Father in heaven. ... If you love those
who love you, what reward will you get? Are not even the tax collectors
doing that? And if you greet only your own people, what are you doing more
than others?" [Matthew 5:43-47]
Received on Monday, 26 March 2012 03:37:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:49:58 UTC