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

2013-12-11 06:18, Karl Tomlinson skrev:
> 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.

Unfortunately, the PannerNode and AudioListener attributes as well as 
the methods setPosition, setOrientation and setVelocity are not 
AudioParams, which means that they can not use automation, and they will 
not receive any smoothing (AFAICT there's no mention of it in the spec 
at least).

To me this feels like a design flaw, but I'm not sure what the practical 
implications are.


/Marcus


>
> 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.
>


-- 
Marcus Geelnard
Technical Lead, Mobile Infrastructure
Opera Software

Received on Wednesday, 11 December 2013 08:59:34 UTC