Re: Behavior of source nodes on connect/disconnect

On Fri, Sep 13, 2013 at 4:23 PM, Jer Noble <jer.noble@apple.com> wrote:

> On Sep 13, 2013, at 4:16 PM, Robert O'Callahan <robert@ocallahan.org>
> wrote:
>
> On Fri, Sep 13, 2013 at 1:50 PM, Jer Noble <jer.noble@apple.com> wrote:
>
>> Of course, HTMLMediaElements must pause when they are removed from the
>> DOM.  So in the general case, disconnecting a playing media element and
>> throwing away all references to it will allow it to be GCd.
>>
>
> But you can call play() on a media element after removing it from the DOM.
>
> If we were to follow the media element model in Web Audio, we would
> introduce per-node pause() and resume() APIs and specify that when you
> disconnect the last output of a node, there is an implicit pause() call.
>
>
> I’d actually be fine with that.
>

I might be too :-).

One further hypothetical: should “pause” and “play” traverse down the
> graph?  I.e., if you “pause” a ConvolutionNode, would the
> AudioBufferSourceNode feeding it pause as well.
>

We need to support transitive pausing in some way, but I'm not totally sure
how it should work.

It might make sense to have a pauseSubgraph() method that behaves like this
on a node N:
-- If N is paused, do nothing and stop. Otherwise:
-- Pause N.
-- Collect a set of nodes S defined by the following:
  -- Add N to S.
  -- If S contains E, and a node M's output is connected to E, and M is not
paused, then add M to S.
(S contains the nodes which feed into N along a path of non-paused nodes.)
-- For each element E of S, if every E output is connected to a node in S,
pause E.
(This pauses all the nodes which don't contribute to outputs other than
through S.)
This means:
* A subgraph of nodes which only produce output via N and where none of
them are all paused, all get paused.
* A node that produces output via N and also along a path not including N
does not get paused.
* If a paused node is connected to N, then pauseSubgraph on N will not
affect the inputs to the already-paused node.

We would then make disconnect() of the last output of a node implicitly
call pauseSubgraph(). We would probably want to add a
disconnectWithoutPausing variant.

For resumeSubgraph(), I would propose this:
-- If N is not paused, do nothing and stop. Otherwise:
-- Collect a set of nodes S defined by the following:
  -- Add N to S.
  -- If S contains E, and a node M's output is connected to E, and M is
paused, then add M to S.
(S contains the nodes which feed into N along a path of paused nodes.)
-- For each element E of S, resume E.
So basically every node that is connected to N along a path of paused nodes
is resumed.

===============

An alternative approach would be to define a "paused" attribute on
AudioNodes with three possible values: "paused", "running", "auto". Then
for each node we compute the "effective paused state", which is true if the
node is "paused", false if the node is "running", and for "auto" nodes is
true if all output node's effective paused states are true. Take the
"greatest fixed point" solution so that nodes in a cycle of "auto" nodes
with no other outputs are paused.

If we start every node in the "auto" state, that would match what Blink
currently does (AIUI). But we could say that a node starts in the "running"
state and switches to the "auto" state when its output is first connected
to another node. That way, standalone nodes would work without any
shenanigans.

Rob
-- 
Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
waanndt  wyeonut  thoo mken.o w  *
*