Should a DynamicsCompressorNode be considered actively processing? #2644
Description
As of now the DynamicsCompressorNode has the default lifetime (https://www.w3.org/TR/webaudio-1.1/#AudioNode-actively-processing) of an AudioNode. It should only become actively processing when one if its inputs is actively processing. However I'm not sure if this was an explicit decision or just never discussed.
Firefox seems to be the only browser implementing the current spec (with a little bug https://bugzilla.mozilla.org/show_bug.cgi?id=1514526). Chrome and Safari do not. They seem to always process the DynamicsCompressorNode. I think both approaches have drawbacks.
When implementing the spec the DynamicsCompressorNode stops processing whenever there is no actively processing input. This could have unwanted consequences when rendering something like a DAW project which may not necessarily have an actively processing input all the time. Think of a drum track with each drum sound scheduled as an individual AudioBufferSourceNode with a DynamicsCompressorNode further down the chain. There are likely gaps between the drum sounds which would cause the DynamicsCompressorNode to pause the internal processing.
On the other hand when implementing the DynamicsCompressorNode as done in Chrome and Safari it may be in an unknown condition when starting playback. Let's say the audio graph gets build at some point to be ready when needed. Later on when the playback actually starts the DynamicsCompressorNode has already processed an undefined amount of silence leading to an unknown internal state and unpredictable results.
I personally think it would be slightly preferable to keep the spec as is. The "problem" with the current spec mentioned above can be easily fixed by playing a silent ConstantSourceNode. But I don't know of any hack to get the spec-ed behavior with what is currently implemented in Chrome and Safari.