Re: ISSUE-5: pausing a subgraph

Hey ROC,

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?


Here is a small graph showing how I am thinking of things in terms of
streaming... hopefully this will help you see where my head is at:

Stream A  \
                Reverb > Destination
Stream B  /

If Stream A stops due to connectivity problems, but Stream B continues,
should I pause the sub-graph?

I would say no.

What am I missing?

--
Alistair



On Thu, Mar 22, 2012 at 3:44 PM, Chris Rogers <crogers@google.com> wrote:

>
>
> 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:
>
> WHEN THE SOURCE IS PAUSED
> 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):
> http://labs.dinahmoe.com/ToneCraft/#
>
> WHEN THE SOURCE IS RESUMED
> 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
> source.
>
> 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.
>
> Chris
>
>
>>
>> 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]
>>
>>
>


-- 
Alistair MacDonald
SignedOn, Inc - W3C Audio WG
Boston, MA, (707) 701-3730
al@signedon.com - http://signedon.com