W3C home > Mailing lists > Public > public-audio@w3.org > October to December 2012

[Bug 17335] (setValueCurveAtTime): AudioParam.setValueCurveAtTime

From: <bugzilla@jessica.w3.org>
Date: Wed, 05 Dec 2012 15:48:51 +0000
To: public-audio@w3.org
Message-ID: <bug-17335-5429-EtH8inChTy@http.www.w3.org/Bugs/Public/>

redman <bugzilla@redman.demon.nl> changed:

           What    |Removed                     |Added
                 CC|                            |bugzilla@redman.demon.nl

--- Comment #5 from redman <bugzilla@redman.demon.nl> ---
(In reply to comment #3)
> (In reply to comment #2)
> > I think the level of detail in the new text is good. One thing that seems to
> > be missing though is what the value is when t < time and t >= time +
> > duration, respectively (most likely values[0] and values[N-1], respectively).
> > 
> > Also, the expression "v(t) = values[N * (t - time) / duration]" is
> > effectively nearest interpolation. Is that intended? Linear interpolation
> > seems more logical.
> The idea is that the number of points in the Float32Array can be large so
> that the curve data is effectively over-sampled and linear interpolation is
> not necessary.
> Fixed:
> https://dvcs.w3.org/hg/audio/rev/a658660f3174

That idea assumes the user creates a 'curve' that is itself sufficiently
oversampled (has way too much data than needed).
If you want to do it right you should provide an interpolator for undersampled
cases and a bandlimiting filter for oversampled cases.
In other words, you should do proper resampling with audio-rate parameters.
Only if the data is played back at its original samplerate can you assume the
data is a valid sample.
Since it is an audio rate controller you should always see it as a signal and
apply signal theory.

You are receiving this mail because:
You are on the CC list for the bug.
Received on Wednesday, 5 December 2012 15:49:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:14 UTC