Tail-time reference should be noted for Convolver, Delay, AudioWorker

[joeberkovitz]

The Lifetime section of the spec http://webaudio.github.io/web-audio-api/#lifetime-1 explains a tail-time reference that pins a node in the graph while it has pending, audible internal state. ConvolverNode is mentioned explicitly as an example of a node with a tail time, and it's stated that descriptions of nodes elsewhere in the document will mention a tail-time reference if it's applicable to that node.

1. The ConvolverNode interface makes no mention of tail-time reference. Presumably it should, since this is the one node that has it for certain.
2. The AudioWorkerNode should probably documented as having a tail-time reference as long as it has an active onaudioprocess handler, since it can act as a source and has an internal state unknown to the audio engine. It could be emitting a signal at any given time.
3. Shouldn't DelayNode have a tail-time as well?

[hoch]

Chrome keeps the tail time internally and does not expose it to JS world. The graph mechanism investigates the tail time and the latency time (pre-delay) of a node every processing block to determine its life time. However, the implementation of this behavior in Chrome is incomplete at the moment.

Internally, we are planning to give tail time and latency time to all the nodes - some nodes will have non-zero value (i.e. DelayNode, ConvolverNode) and others have zero value. We believe this is a future-proof method making it easier to manage the audio graph.

I am not sure if these values should be exposed to JS or AudioWorker (maybe we should for Worker...), but the concept should definitely be in the spec.

[cwilso]

Related: #9 .

[rtoy]

Biquad filters and WaveShaperNodes (with oversampling) have tail time and latency as well.

[joeberkovitz]

Can this be marked Ready for Editing? What remains to be decided?

[hoch]

Here are some follow-up questions:

• Do implementors have to expose node.tailTime attribute as a read-only value?
• What about the node with the variable tail time? (i.e. delay, convolution, biquad...)
• If they can be changed dynamically, what level of accuracy do we want to have in terms of updating/getting this value?

[joeberkovitz]

• We did not discuss exposing this time in the API. Is there a good reason we must do so? It will create additional issues with determining the current tail time (as you pointed out).
• I do not think there is any issue with having variable tail times providing they are well-defined based on the node state.

[rtoy]

On Tue, May 5, 2015 at 1:01 PM, Joe Berkovitz notifications@github.com
wrote:

We did not discuss exposing this time in the API. Is there a good
reason we must do so? It will create additional issues with determining the
current tail time (as you pointed out).

​I don't see any reason to expose it. What would the user do with it?
All I could think of is disconnecting the node after the tail time. But
the implementation could do that itself. Or at least optimize the case
where the tail-time has passed.​

I do not think there is any issue with having variable tail times
providing they are well-defined based on the node state.

​I agree. It's a bug in the implementation if there should be non-zero
output and there isn't.​

—
Reply to this email directly or view it on GitHub
#414 (comment)
.

Ray

[joeberkovitz]

F2F Resolution: we're going to mention the existence of tail-time for nodes that have it but leave unquantified and unexposed via the API for V1.