W3C home > Mailing lists > Public > public-audio@w3.org > October to December 2012

Re: Web Audio API sequencer capabilities

From: Srikumar Karaikudi Subramanian <srikumarks@gmail.com>
Date: Tue, 9 Oct 2012 05:29:40 +0530
Cc: Patrick Borgeat <patrick.borgeat@gmail.com>, Joe Berkovitz <joe@noteflight.com>, Jussi Kalliokoski <jussi.kalliokoski@gmail.com>, "public-audio@w3.org Group" <public-audio@w3.org>
Message-Id: <6AD59DBA-1A68-4CCC-9173-230A1E872792@gmail.com>
To: Chris Rogers <crogers@google.com>

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. 

Received on Tuesday, 9 October 2012 00:00:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:14 UTC