W3C home > Mailing lists > Public > public-audio@w3.org > April to June 2012

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

From: Audio Working Group Issue Tracker <sysbot+tracker@w3.org>
Date: Fri, 18 May 2012 14:14:03 +0000
Message-Id: <E1SVNwR-0003CX-Mw@tibor.w3.org>
To: public-audio@w3.org
Audio-ISSUE-94 (DynamicLifetime): Dynamic Lifetime [Web Audio API]

http://www.w3.org/2011/audio/track/issues/94

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

https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html#DynamicLifetime

"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.
Received on Friday, 18 May 2012 14:14:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 18 May 2012 14:14:09 GMT