- From: Raymond Toy <rtoy@google.com>
- Date: Thu, 12 Sep 2013 15:14:36 -0700
- To: Chris Wilson <cwilso@google.com>
- Cc: "public-audio@w3.org" <public-audio@w3.org>
- Message-ID: <CAE3TgXGCgdZ0JgMuZSpRVAAK3sRfx+ruLX6_Spa+oCE-TjcrGw@mail.gmail.com>
On Thu, Sep 12, 2013 at 2:59 PM, Chris Wilson <cwilso@google.com> wrote: > I believe the current understanding is that the nodes would all keep > playing as if they were connected; that is: > > >If you have a (long) source node that has started playing and then you > disconnect it (completely) after 1 sec from one part of the graph and then > wait for, say, 1 sec, and connect it to a different (or same?) part of the > graph, what should happen? > > You would "hear" it continue playing (so, from approximately 2 secs in to > the source node content). > Agreed. > > >A different scenario: You've started playing a source node, and then > completely disconnect it from the graph and then add a onended listener. > What should happen? Does the onended listener get called when the source > would normally end? > > If you've added an onended listener, that keeps the node alive, and it > would fire when the node finished playing (despite it having been > disconnected previously). > Agreed. > > >Another scenario: Say you have a source node attached to a sub graph > that isn't currently attached to the destination. If you start(0) the > source node, and then later on connect the subgraph to the destination, > what should happen? > > It "continues" from wherever it is in playback when you connect() it. > That includes time side effects - e.g. if the subgraph includes a > convolution or delay node, those effects from previous data would be > applied. > Hmm. I agree in principle, but this is somewhat problematic in Chrome today, I think. More thinking needed. > > >Or say you don't connect the subgraph, but have an onended listener for > the source. The listener should get fired, once the source is started? > > Once the source has finished, yes. (if the source is a 5 second buffer, > you would get onended fired approximately 5 seconds after start(0) is > called.) > > Agreed. > This model is akin to plugging patch cords between nodes, which I've > always found the most intuitive from a developer perspective; Chris > disagreed with me on this for quite a while, but I think he'd come around. > The patch cord idea is very intuitive. I think the implementation in Blink, however, is a bit troublesome since the destination pulls on the graph to get data, and if a cord is not connected, it never gets pulled. I'm not sure how to do this effectively. Does the spec imply that this is how it works? I couldn't find anything definitive. > > -Chris > > > On Thu, Sep 12, 2013 at 2:46 PM, Raymond Toy <rtoy@google.com> wrote: > >> Another scenario: Say you have a source node attached to a sub graph >> that isn't currently attached to the destination. If you start(0) the >> source node, and then later on connect the subgraph to the destination, >> what should happen? >> >> Or say you don't connect the subgraph, but have an onended listener for >> the source. The listener should get fired, once the source is started? >> >> >> On Thu, Sep 12, 2013 at 1:51 PM, Raymond Toy <rtoy@google.com> wrote: >> >>> While fixing a different issue in Chrome's webaudio, the following >>> questions came up. >>> >>> If you have a (long) source node that has started playing and then you >>> disconnect it (completely) after 1 sec from one part of the graph and then >>> wait for, say, 1 sec, and connect it to a different (or same?) part of the >>> graph, what should happen? Does the node start playing again? What does >>> it play? The source starting at time 2 sec? >>> >>> A different scenario: You've started playing a source node, and then >>> completely disconnect it from the graph and then add a onended listener. >>> What should happen? Does the onended listener get called when the source >>> would normally end? >>> >>> I think these are not scenarios that would normally occur, but it came >>> up during a review, and I didn't know the answer. >>> >>> Help! >>> >>> Ray >>> >>> >> >
Received on Thursday, 12 September 2013 22:15:04 UTC