On Mon, Oct 8, 2012 at 4:59 PM, Srikumar Karaikudi Subramanian < srikumarks@gmail.com> wrote: > > On 9 Oct, 2012, at 1:00 AM, Chris Rogers <crogers@google.com> wrote: > > On Sat, Oct 6, 2012 at 1:09 AM, Patrick Borgeat <patrick.borgeat@gmail.com > > wrote: > >> >> Since the GainNode doesn't produce a signal we would need to feed him a >> Unity signal, but all the possibilities I see in the API would require the >> developer to specify the lifetime of the unity signal (I think it would be >> more straightforward for a UnitySourceNode to be collected automatically). >> >> > I think Joe already mentioned this, but if an AudioBufferSourceNode is in > "loop" mode, then it's not necessary to manage it's lifetime, and it will > simply play forever until gc. Also, if an application often needs to deal > with these "unity sources", then it's pretty easy to just create a single > one, then share it among any nodes needing it. > > > I'm not sure how the "shared unity source" approach can work in the > general case. If the singleton source is fed into multiple nodes, and one > part of this graph is to be trashed, we cannot disconnect only that > connection. A disconnect() call on the unity source node would disconnect > all the connections of the shared unity source. If we disconnect only some > terminal node of subgraph fed by the unity source, then the nodes in that > subgraph will continue to survive GC if I understand correctly. > > The only approach I see is to create separate unity sources for each > dynamic part of the audio graph that needs one. > > You're right, I was overgeneralizing the usefulness of sharing a single unity source. For long-lived parts of the graph they could be used, but each dynamic part needs its own... Chris > Best, > -Kumar >
Received on Tuesday, 9 October 2012 01:48:18 UTC