Re: Consensus gathering for the Dezippering issue

Chris Lowis writes:

> On the call the participants reached a consensus to:
>  1) Keep dezippering in the spec
>  2) Apply it universally to all parameters (such that there are no
> "edge cases" in the spec

Is someone able to elaborate, please on the reason for the change
in viewpoint?  Previously, most people on this list seemed to be
in the explicit-is-better-than-implicit camp.

> 2) Removing it would indeed result in some audible glitches

Is this the reason?

Currently AFAIS smoothing is only specified for DelayNode and
GainNode.  We could leave the smoothing on these nodes for
backward compatibility, but not introduce any new smoothing.

Note that AudioParam documentation says "The parameter can be set
immediately to a particular value using the value attribute", so
it is the node, not that parameter, that is currently required to
apply the smoothing.  That makes sense because it is the node that
knows what kind of smoothing is required to avoid glitches.

However, this is actually a problem if not handled carefully
because smoothing the final or intrinsic value, would mean that
setValueAtTime() wouldn't produce a step function change in the
delay or gain, and other transient changes also won't be exact.
IIUC the webkit implementation only smooths the value from the
AudioParam.value setter and that only if there are no AudioNodes
connected.  Gecko has copied a similar implementation, I assume.

If we keep the smoothing, and there is a case for that on these
nodes, then I think only the changes from the AudioParam.value
setter should be smoothed.  A decision is also required on whether
to smooth these changes when an AudioNode is connected to the

I assume that setting |value| to something other than defaultValue
soon after creating the node, before connecting the node or
something, would not leave the AudioParam starting from the
defaultValue, but would start from the value set, without

Received on Thursday, 5 December 2013 01:03:35 UTC