W3C home > Mailing lists > Public > public-audio@w3.org > January to March 2015

Dynamic Lifetime and AudioWorker

From: Steven Yi <stevenyi@gmail.com>
Date: Tue, 3 Feb 2015 19:13:58 -0500
Message-ID: <CANtcCs6-8XtdFnJAgpFQveh6cu0o7KR88EkkEbtgyDtT8KUWyQ@mail.gmail.com>
To: public-audio@w3.org
Hi All,

In regards to section 4 of the draft spec entitled "Dynamic Lifetime"
(http://webaudio.github.io/web-audio-api/#dynamic-lifetime), as well
as section 2.3.3's discussion of "tail-time" reference, there seems to
be two separate features here that I'm wondering if they've been
considered for AudioWorkers.  Also, there are some points I'd like to
request some clarification on. My questions regarding these are:

# In regards to section 4, there is the following:

" A "note" is represented by an AudioBufferSourceNode, which can be
directly connected to other processing nodes. When the note has
finished playing, the context will automatically release the reference
to theAudioBufferSourceNode, which in turn will release references to
any nodes it is connected to, and so on."

1. Will it be possible for an AudioWorker to signal a release,
similarly to how the above AudioBufferSourceNode can signal turning
off? (An imagined use case is below.)

2. Does this release signal correspond to the "onended" event handler,
discussed in 2.9.1?

3. If so, from the documentation to AudioBufferSourceNode, could some
text be added to clarify when an ended event will be fired?  (perhaps
something like "An ended event will fire when either the node is set
to not loop and the end of audio buffer data is read, or if stop() is
explicitly called.")

4. Also if 1 & 2, should AudioWorker have an onended event handler
property? Also, if this is added, it seems like an
AudioWorkerContext's onaudioprocess code would need an "ended"
property or a setEnded() function (or playing/isPlaying())

5. Regarding Example 4.2, Figure 7, if the Compressor did not have any
the Stream Source and Gain 1 nodes, what prevents the Compressor node
from also being released when the AudioBufferSourceNode is released?
>From reading the spec, it seems like it would get killed off once the
last Node that is attached is detached.

Use Case for AudioWorker: A user initiates a "note" via a MIDI
keyboard.  An AudioWorker that implements a combined envelope
generator + VCA is used to process the output of a set of
OscillatorNodes, and these are all added to the main audio graph. When
the user depresses the key, a message is posted to the AudioWorker to
go into a release stage.  At the end of the release stage, the
AudioWorker could fire an end event, cleaning up the set of nodes.

# In regards to 2.3.3, it mentions that:

"A tail-time reference which an AudioNode maintains on itself as long
as it has any internal processing state which has not yet been
emitted. For example, aConvolverNode has a tail which continues to
play even after receiving silent input (think about clapping your
hands in a large concert hall and continuing to hear the sound
reverberate throughout the hall). Some AudioNodes have this property.
Please see details for specific nodes."

1. I went to look at the details for ConvolverNode but there was no
mention of the tail-time.  I find the text a little confusing.  My
first interpretation was that the tail-time is a feature of some nodes
to extend its own processing time past when something like stop() is
called, as a scenario like would make sense in terms of lifetime.
However, I can't seem to make any conclusive interpretation from the
spec alone.  Could I request some clarification on tail-time?

2. If 1 above is a correct interpretation, will it be possible for an
AudioWorker to specify it's own tail-time?

Use Case: User defines a custom reverb using AudioWorker and wants it
to have the same behavior in terms of lifetime as a ConvolverNode.

# In regards to lifetime, I also noted this text (in 2.3.3, point 4):

"A connection reference which occurs if another AudioNode is connected to it."

1. Is this correct? It seems backwards to me, and that a connection
reference should be established if a Node is itself connected to
another node, and that it is either directly or transitively connected
to the AudioDestinationNode of the AudioContext.  Otherwise, you can
have a PannerNode with no connections to it, connected to the
AudioDestinationNode, and it would have neither a normal, playing,
connection, nor tail-time reference.  (To note, the text that follows
that point mentions cycles connected to the AudioDestinationNode will
be kept alive, but that doesn't seem to apply to this as it's not a

Received on Wednesday, 4 February 2015 00:14:26 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 4 February 2015 00:14:27 UTC