Re: Consensus gathering for the Dezippering issue - blink processing

On Thu, 5 Dec 2013 09:57:28 +0000, Olivier Thereaux wrote:

> On 5 Dec 2013, at 01:02, Karl Tomlinson <> wrote:
>> 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.
> See the minutes of our last teleconference for details:
> It was tossup. We went for “paving the cowpaths” and standardising the
> behaviour in Blink/Webkit. Given the quorum at the teleconference, there was
> an obvious need to check that other implementors and WG members could live
> with this, hence this CfC.

I had a look at what Blink code does, so I'll post my notes here
for reference.  (I don't know whether or not this differs from

When there are no nodes connected to an AudioParam, changes from
the value setter are smoothed using a function similar
setTargetAtTime() on these nodes:

  BiquadFilterNode and OscillatorNode use a factor of 0.95 per
  sample interval, which at 44.1 kHz is roughly equivalent to a
  time constant of 0.44ms.

  GainNode uses a factor of 0.995 per sample, which at 44.1 kHz is
  roughly equivalent to a time constant of 4.5 ms.

  DelayNode uses a time constant of 20 ms, independent of sample

I don't see any smoothing on AudioBufferSourceNode.playbackRate or
in DynamicsCompressorNode.

There is also smoothing in PannerNode that is not applied to
AudioParams, but to functions of double attributes.  Cone and
distance gain are smoothed using a time constant around 4.5 ms at
44.1 kHz, and the time constant for smoothing the panning gain is
50 ms independent of the sample rate.

In Gecko, the only smoothing of attributes that I know of is on

Received on Wednesday, 11 December 2013 05:14:46 UTC