Re: Behavior of source nodes on connect/disconnect

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

> On Sep 13, 2013, at 12:47 PM, Robert O'Callahan <robert@ocallahan.org>
> wrote:
>
> On Fri, Sep 13, 2013 at 8:39 AM, Jer Noble <jer.noble@apple.com> wrote:
>
>> I’m going to have to take up the mantle of Chris and disagree with you
>> strongly here.  Disconnected nodes are disassociated from the graph
>> entirely.  They do not participate in rendering to the destination node,
>> and they no longer are connected to the destination node’s timeline.
>>
>
> OK, but that's not what the spec currently says and adding that behavior
> to the spec is a large change. So this discussion should really be framed
> as a proposal to make this change to the spec. As such, it would be helpful
> to see the proposed change written down in more detail.
>
>
> Since the spec is entirely silent (pun most definitely intended) on the
> issue, it’ll be a spec change either way.
>

No. If the spec doesn't say A affects B, then it means A does not affect B.
For example, the spec is silent on whether drawing an image to a canvas
affects audio playback. That does not mean there is an issue that needs to
be resolved.

You may consider this issue unresolved, and that's a valid point of view,
but if we resolve it by saying that output connection state does not affect
node playback, then we don't need to make any change to the spec.


> Philosophically speaking, disconnected nodes are collected by GC because
>> they are no longer active. But if disconnected nodes continue to "play", we
>> would either be GCing active objects, or not GCing disconnected objects,
>> effectively leaking nodes with no end time.  Neither of which are good
>> options.
>>
>
> In most cases, the ongoing playback of disconnected nodes is not
> observable, and therefore they can be safely destroyed even though they're
> active.
>
>
> That is why it was a philosophical, not practical objection. ;)
>

All issues to do with GC are practical only. GC is an optimization, nothing
more.


> Practically speaking, disconnecting a sub-graph is the only way deleopers
>> can "pause" playback. If we force disconnected nodes to continue playing,
>> the only way to pause playback would be to entirely tear down and re-create
>> a subgraph.
>>
>
> I agree with Chris Wilson; if we're going to support pausing, let's
> support it properly with a pause/resume API.
>
> Pausing a MediaStream/ElementAudioSourceNode is not a problem. You just
> drop data from the input stream while paused.
>
>
> We’ve asked for a pause()/resume() API in the past and never got anywhere.
>  See: <https://www.w3.org/2011/audio/track/issues/5>
>

Chris Rogers argued that you could pause a subgraph by shutting off all its
inputs, and resume it by recreating those inputs. I don't think that's
adequate.

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  *
*