W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2013

[web-audio-api] (DynamicLifetime): Dynamic Lifetime (#161)

From: Olivier Thereaux <notifications@github.com>
Date: Wed, 11 Sep 2013 07:28:43 -0700
To: WebAudio/web-audio-api <web-audio-api@noreply.github.com>
Message-ID: <WebAudio/web-audio-api/issues/161@github.com>
> Originally reported on W3C Bugzilla [ISSUE-17405](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17405) Tue, 05 Jun 2012 12:30:36 GMT
> Reported by Michael[tm] Smith
> Assigned to 

Audio-ISSUE-94 (DynamicLifetime): Dynamic Lifetime [Web Audio API]


Raised by: Philip J├Ągenstedt
On product: Web Audio API


"When the note has finished playing, the context will automatically release the reference to the AudioBufferSourceNode, which in turn will release references to any nodes it is connected to, and so on. The nodes will automatically get disconnected from the graph and will be deleted when they have no more references. Nodes in the graph which are long-lived and shared between dynamic voices can be managed explicitly."

This look like a requirement on the implementation, but it's not normative or detailed enough to test or implement.

The above quoted text appears to not be the wanted behavior, unless "has a reference" means "can produce output". For example, if an AudioBufferSourceNode produces output for n milliseconds and is followed by a DelayNode with delay n milliseconds, certainly the lifetime of the delay node should be 2*n. To collect all of the downstream elements because the AudioBufferSourceNode reaches FINISHED_STATE is not sensible. If circular routing is allowed (https://www.w3.org/2011/audio/track/issues/24) it will be possible to create subgraphs which never stop producing output and can (should) thus never be collected.

For reference, HTMLMediaElement has the concept of "potentially playing" and is not destroyed while it may still produce output. Something similar for the Web Audio API seems logical, as the result would otherwise be sensitive to GC intervals.

Reply to this email directly or view it on GitHub:
Received on Wednesday, 11 September 2013 14:29:06 UTC

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