Re: Consensus gathering for the Dezippering issue

2013-12-05 02:02, Karl Tomlinson skrev:
> 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.

I too see an issue if we have this opt-out design: setting the value 
attribute could become a big no-no for developers. As I like explicit 
interfaces, I'd personally always use the "automation methods" rather 
than the value attribute if the latter is not equal to setValueAtTime.

On the other hand, having all parameters behaving the same way (for the 
sake of consistency) is important so I can live with all on (though I'd 
prefer all off).


>> 2) Removing it would indeed result in some audible glitches
> Is this the reason?
>
> Currently AFAIS smoothing is only specified for DelayNode and
> GainNode.  We could leave the smoothing on these nodes for
> backward compatibility, but not introduce any new smoothing.
>
> Note that AudioParam documentation says "The parameter can be set
> immediately to a particular value using the value attribute", so
> it is the node, not that parameter, that is currently required to
> apply the smoothing.  That makes sense because it is the node that
> knows what kind of smoothing is required to avoid glitches.
>
> However, this is actually a problem if not handled carefully
> because smoothing the final or intrinsic value, would mean that
> setValueAtTime() wouldn't produce a step function change in the
> delay or gain, and other transient changes also won't be exact.
> IIUC the webkit implementation only smooths the value from the
> AudioParam.value setter and that only if there are no AudioNodes
> connected.  Gecko has copied a similar implementation, I assume.

This is a very important point. The current spec language for the 
DelayNode is much too vague on this point: "When the delay time is 
changed, the implementation must make the transition smoothly, without 
introducing noticeable clicks or glitches to the audio stream.". As a 
developer, I would take this to mean that no matter what method I use 
for changing the delayTime parameter, the client should guarantee 
smoothing (i.e. apply smoothing to the final value). If that's true, and 
it's the desired mode of operation, I think we have some more work to do...

>
> If we keep the smoothing, and there is a case for that on these
> nodes, then I think only the changes from the AudioParam.value
> setter should be smoothed.  A decision is also required on whether
> to smooth these changes when an AudioNode is connected to the
> AudioParam.
>
> I assume that setting |value| to something other than defaultValue
> soon after creating the node, before connecting the node or
> something, would not leave the AudioParam starting from the
> defaultValue, but would start from the value set, without
> smoothing.
>


I think that most of these problems will magically go away if we make 
sure to specify something like "Setting the value attribute to X must 
have the same effect as calling methodBlaBla with arguments X, Y (, 
...)". Provided that it's what we want, that is.


/Marcus

-- 
Marcus Geelnard
Technical Lead, Mobile Infrastructure
Opera Software

Received on Thursday, 5 December 2013 09:37:23 UTC