- From: <bugzilla@jessica.w3.org>
- Date: Wed, 05 Dec 2012 10:20:25 +0000
- To: public-audio@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17335
Marcus Geelnard (Opera) <mage@opera.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |---
--- Comment #4 from Marcus Geelnard (Opera) <mage@opera.com> ---
(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
Looks good for t >= time + duration. As for t < time, I guess the curve is not
active, so needs not be defined (?).
Why don't we want linear interpolation? Linear interpolation would make the
interface much easier to use, and could save a lot of memory. E.g. a plain ramp
would occupy 256 KB for 16-bit precision without linear interpolation (and
require a fair amount of JavaScript processing to generate the ramp). With
linear interpolation the same ramp could be accomplished by a 2-entry
Float32Array and minimal JavaScript processing.
I don't think that linear interpolation would cost much more in terms of
performance, especially not compared to e.g. the exponential ramp.
--
You are receiving this mail because:
You are on the CC list for the bug.
Received on Wednesday, 5 December 2012 10:21:29 UTC