-
Notifications
You must be signed in to change notification settings - Fork 166
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(DynamicLifetime): Dynamic Lifetime #161
Comments
[admin] Assigning items currently being worked on by editor. |
Changeset from the editor: Detailed text added: |
Awaiting feedback. |
The tail-time for specific AudioNodes need to be defined. In particular, what tail-time should a JavaScriptAudioNode have? |
The Lifetime section(s) are now informative, or about to be made informative (see e.g Bug #21523). Seems like this bug should be closed as a result. |
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.
The text was updated successfully, but these errors were encountered: