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

Re: ISSUE-5: pausing a subgraph

From: Chris Rogers <crogers@google.com>
Date: Thu, 22 Mar 2012 12:44:52 -0700
Message-ID: <CA+EzO0kLO0GCEG7WP2v0f+GPN7ikCbhf+FW6AcANUtZTEskrEA@mail.gmail.com>
To: robert@ocallahan.org
Cc: olivier Thereaux <olivier.thereaux@bbc.co.uk>, public-audio@w3.org, jussi.kalliokoski@gmail.com
On Wed, Mar 21, 2012 at 9:56 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Wed, Mar 21, 2012 at 5:29 AM, olivier Thereaux <
> olivier.thereaux@bbc.co.uk> wrote:
>> Could you have a look at it and tell me:
>> * Whether the page correctly records the conversation and the issue (and
>> whether I've missed anything), and
>> * Whether the discussion during the teleconference on March 5th, where
>> Chris stated there was sufficient control in the API, can be considered a
>> suitable resolution to the issue
>> ?
> It sounds like Chris is saying that you can pause a subgraph by pausing
> all its inputs.

For dealing with arbitrary parts of the graph (sub-graphs or sub-mixes) one
technique is to control the .gain parameter on an AudioGainNode which
controls the overall volume for that part of the graph.  The gain/volume
transition can be made suddenly or slowly faded out at precise times.
 Another technique is to simply stop scheduling any new "notes" from
playing in AudioBufferSourceNodes, and by stopping any currently playing
notes by calling the noteOff() method.  Sometimes, it will be a good idea
to schedule the noteOff() to not happen immediately, but to wait for the
exact time that a loop reaches its end.

> It seems to me that wouldn't be satisfactory. First of all, there are no
> guarantees that explicitly pausing each input will pause them all at
> exactly the same moment, so pausing and resuming would break
> synchronization.

AudioBufferSourceNodes can be scheduled to happen at exact times.  So their
start and end times can be given precisely and will be synchronized.

> Secondly, this approach doesn't pause filter processing, and for many
> applications pausing the inputs (and treating them as silence, which I
> think is what Web Audio would do) would give different results from pausing
> the subgraph. For example, if you have a filter producing echoes, you will
> hear an echo after you pause the inputs, which is not what you want if you
> wanted to pause the subgraph.

It's interesting to discuss this type of scenario in more detail.  In a
simple case let's consider a simple source feeding into an "echo" or
"reverb" efffect:

source -> reverb -> destination

If the source is playing for a while with the echo/reverb effect, then
paused for a little while, then later resumed let's see what the possible
behaviors could be:

1. When paused all sound stops immediately.
2. When paused the sound from the source stops immediately, but the echo
(tail of the reverb) continues to play until it dies down completely.

Either (1) or (2) may be the desired behavior.  As an example of (2) please
see ToneCraft in Chrome or Safari nightly (when playback is paused with the
space bar):

When paused according to (1)
1a. The echo/reverb is heard from old (before pausing) sounds played by the
source, layered on top of echo/reverb from the new (resumed) sounds from
the source.
1b. The echo/reverb is heard only from the new (resumed) sounds from the

When paused according to (2)
2a. The echo/reverb is heard from the current (resumed) source layered on
top of the uninterrupted/continuous previous echo/reverb

1a is considered to be anomalous behavior in musical applications since it
abruptly re-introduces old/stale echo/reverb state into the rendered audio
stream.  It can be caused by a filter (echo/reverb in this case) not having
its state reset properly at the moment of "pausing" for case (1).

1b and 2a would be the desired behavior respectively for pause types (1)
and (2).

> Thirdly, having to explicitly pause each input is not very convenient. If
> an app developer wants to be able to pause the output of some complicated
> graph, they have to keep track of all the active inputs themselves.

I'm going to disagree with you on this point.  In many cases "pausing" can
be as simple as adjusting a sub-mix gain, or simply allowing existing
"one-shot" sounds to finish and stop scheduling new notes.  In other cases
for continuously playing/looping sounds, it's not really that difficult to
keep track of the relevant active sources.


> ProcessedMediaStreams does allow pausing of subgraphs.
> Rob
> --
> “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 Thursday, 22 March 2012 19:45:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:02 UTC