Re: Resolution on de-zippering Re: [CfC] Consensus gathering for the Dezippering issue

Olivier Thereaux writes:

> We discussed this issue again at our last teleconference, and confirmed the
> resolution to have .value effectively be an alias for setTargetAtTime() - with
> time constants TBD.

If the .value setter were required to behave equivalently to
setTargetAtTime(newValue, TBDStartTime, TBDTimeConstant), then it
would become a problem for DelayNode implementations to "make
the transition smoothly, without introducing noticeable clicks or
glitches to the audio stream."

The current Blink and Gecko implementations don't make the
transition smoothly with setTargetAtTime.  I understand the
general consensus was that the values from the client-specified
automation functions should be used directly.  These DelayNode
implementations could be changed to transition smoothly even for
automation method changes, but this would remove control from the
client, which may wish to change the delay immediately or generate
controlled Doppler effects.

> On 23 Dec 2013, at 10:04, Karl Tomlinson <> wrote:
>> Using an AudioParam transition to dezipper prevents nasty
>> surprises on a GainNode, but applying the same transition to some
>> other AudioParams would /introduce/ nasty surprises.
> Understood, but from what I gathered from our discussions, the
> group favoured consistency and clarity over the management of
> many edge case which may or may not “do the right thing”.

Thank you for the explanation.

If consistency and clarity is preferred over doing the right
thing, then please don't require any added magic, but leave the
.value setter as making the change immediately for all
AudioParams.  That is the clearest solution and doesn't introduce
any unexpected effects.

> If .value is an alias to setTargetAtTime (and thus systematically smoothed)
> and the spec makes it clear that non-smoothed transition can be achieved
> through SetValueAtTime(),

A non-smoothed transition would not be possible for DelayNode, as
explained above.

Received on Tuesday, 24 December 2013 02:22:22 UTC