Re: [CfC] Consensus gathering for the Dezippering issue

On Tue, 17 Dec 2013 08:59:56 +0000, Olivier Thereaux wrote:

> Looking at responses to the CfC,
> http://lists.w3.org/Archives/Public/public-audio/2013OctDec/0311.html

> * There was some disagreement on point 2 - whether having
> smoothing on all audioparams would be better than introducing
> edge cases. No clear objection,

Thank you for the opportunity to comment.
Please consider my reply to be an objection.

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.

Chris's OscillatorNode frequency demo [1] has already demonstrated
surprises when loaded in Chromium.

I did some experimentation with DelayNode to reproduce some even
more catchy surprises.

  [2] demonstrates a change in DelayNode delayTime with no
  transition (using setValueAtTime()) when applied to a sine wave.
  There are, as expected, obvious glitches at the changes.

  [3] uses the delayTime.value setter, where both Blink and Gecko
  apply a setTargetAtTime-like transition, but this only makes
  things much worse.  Listen to transitions to and from silence
  during the initial 10 seconds after page load, as well as later
  the transitions to and from different phases in the sine wave.

The problem is that a transition in the AudioParam at least
introduces a huge frequency shift, and, in these implementations,
also other discontinuities.

"When the delay time is changed, the implementation must make the
transition smoothly, without introducing noticeable clicks or
glitches to the audio stream", but both implementations completely
fail to remove glitches by emulating setTargetAtTime(), instead
introducing more.

The implementation needs to use a different technique to make the
transition smoothly.  A cross-fade [4] seems a far superior
technique for this node.  Note that a cross-fade is not a
transition on the AudioParam intrinsic value, but needs to be
performed by the DelayNode.

Is this enough evidence that applying the same transition
"universally to all" AudioParams is not the way to remove nasty
surprises?

> but I’d like to give Karl and others a chance to propose a
> comprehensive list of params which would, or would not, be
> smoothed when changing .value.

Clearly GainNode and AudioBufferSource frequency and DelayNode
delayTime parameters do not benefit and should not have these
AudioParam transitions.  However, the key list is which
AudioParams *should* be smoothed.  I have proposed that only the
nodes for which the spec currently requires special smoothing,
DelayNode and GainNode, do so, but I'm willing to add other cases,
if the need is demonstrated.

Introducing a transition to any AudioParam comes with the cost
that the intrinsic value will not be equal to the value that it
was set to until some time after it is set.  This is noticeable in
[1] even when pressing "Click me" the first time (or the first
time after "Stop").  A GainNode is used to gently switch on the
oscillator signal at the same time as setting the frequency.  In
Chromium, instead of the new frequency fading in, the old
frequency is heard first.

Transitions should certainly not be introduced where they do not
effectively remove nasty surprises.  I haven't experimented with
other AudioParams to determine whether immediate changes cause
unpleasant glitches nor whether AudioParam transitions are the
best ways to smooth out these glitches.  This should happen on
each node, and the benefit should be weighed against the cost,
before adding requirements for smoothing on new nodes.

[1] http://blog.chrislowis.co.uk/demos/dezippering/
[2] http://people.mozilla.org/~karlt/delay-changes-sudden.html
[3] http://people.mozilla.org/~karlt/delay-changes.html
[4] http://people.mozilla.org/~karlt/delay-changes-cross-fade.html

Received on Monday, 23 December 2013 10:06:29 UTC