Re: [CfC] Re: Consensus gathering for the Dezippering issue

On Wed, 4 Dec 2013 10:52:29 +0000, Olivier Thereaux wrote:

> On 3 Dec 2013, at 19:58, Chris Lowis <chris.lowis@gmail.com> wrote:
>> 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
>> 3) Define it in terms of one of the other methods (probably
>> exponentialRampToValueAtTime) to simplify the spec and also to
>> indicate to developers how to achieve parameter changes without
>> dezippering by using those methods directly.
>>
>> I think Olivier would like to consider this a Call for
>> Consensus, so if I've missed anything, please say
>> so. Otherwise, if we agree on the above approach then we can
>> start turning this into a PR against the current spec.
>
> Yes. Let's set a deadline on now()+1 week (that is 2013-12-11)
> for consensus on the approach.
>
> By that I mean:
>
> * Consensus on point 1) above

I agree that some smoothing needs to be performed.

When setting double attributes on PannerNode and AudioListener,
there is no way for the client to make these transitions smooth,
so the implementation needs to do this.

There are some nodes where step function changes in some
parameters will produce glitches in the audio output.  Either we
need to provide a new AudioParam method to allow smooth changes to
be made immediately, or the implementation of these nodes needs to
smooth changes applied by the setter.

Keeping the requirements for implementations to handle this in
DelayNode and GainNode is sensible.

There should be clarification that this smoothing is not applied
to values from connected AudioNodes or from automation methods,
and whether or not this smoothing is applied to setter changes
when there are AudioNodes connected. 

> * Consensus on point 2) above

I think universal smoothing of all parameters would be bad.

The argument for universal smoothing is consistency, but these
AudioParams apply to different kinds of parameters, and so
different smoothing will be suitable for different parameters, and
some parameters will not require smoothing.

GainNode.gain applies directly to the sample values.
DelayNode.delay roughly changes the samples involved.
AudioBufferSourceNode.playbackRate and OscillatorNode.frequency
are similar to changes in the derivative of DelayNode.delay.

Double attributes on AnalyserNode don't need smoothing and
smoothing double attributes on AudioBufferSourceNode would seem a
little crazy, I think.

I haven't noticed a situation where
AudioBufferSourceNode.playbackRate and OscillatorNode.frequency
need smoothing, and I think they are better off without smoothing.

I think the way to move forward here is to investigate the
individual parameters.  Perhaps we can find classes of parameters
where smoothing is applied consistently with the class, if the
class needs smoothing.

I would expect k-rate parameters to require no smoothing given
"For each 128 sample-frame block, the value of a k-rate parameter
must be sampled at the time of the very first sample-frame, and
that value must be used for the entire block."  However,
BiquadFilterNode looks a good candidate for smoothing.

> * Consensus in principle on point 3) above, excluding detailed agreement on
> how we will define it for each/all parameters.

The methods on AudioParam are not suitable for applying transient
changes immediately, so this would not be a good example for
developers.

I expect we can come up with a similar mathematical function or
functions to those involved in AudioParam methods, but the
parameters are different because AudioParam methods are designed
for scheduling effects in the future.  We don't have a good way to
specify the start time to be "as soon as possible" or to specify
the duration of the transition.

In some places it may be easier to determine appropriate smoothing
of a function of the node attributes, than the attributes
themselves.  For example, smoothing the biquad filter coefficients
may be more intuitive than smoothing the node parameters.
Smoothing the final values of PannerNode output may be more
efficient than smoothing every parameter involved, requiring
everything to be recomputed for every sample.

Received on Wednesday, 11 December 2013 05:19:04 UTC