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

[Bug 17335] (setValueCurveAtTime): AudioParam.setValueCurveAtTime

From: <bugzilla@jessica.w3.org>
Date: Thu, 06 Dec 2012 08:38:35 +0000
To: public-audio@w3.org
Message-ID: <bug-17335-5429-ygP2tJvS3S@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17335

--- Comment #6 from Marcus Geelnard (Opera) <mage@opera.com> ---
(In reply to comment #5)
> Since it is an audio rate controller you should always see it as a signal
> and apply signal theory.

True, but in this case I think that the real use case is to use quite
low-frequency signals (like various forms of ramps that run for at least 20 ms
or so). For those scenarios, band-limiting should not be necessary. As long as
the spec mandates a certain method of interpolation (e.g. nearest, linear or
cubic spline), the user knows what to expect and will not try to make other
things with it (like modulating a signal with a high-frequency waveform).

Also, I think it's important that all implementations behave equally here,
because different interpolation & filtering methods can lead to quite different
results. E.g. a 5 second fade-out would sound quite different if it used
nearest interpolation instead of cubic spline interpolation. In that respect, a
simpler and more performance friendly solution (like nearest or linear
interpolation) is better, because it's easier to mandate for all
implementations.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Thursday, 6 December 2012 08:38:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:03 UTC