W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2013

Re: [web-audio-api] (setValueCurveAtTime): AudioParam.setValueCurveAtTime (#131)

From: Olivier Thereaux <notifications@github.com>
Date: Wed, 11 Sep 2013 07:29:53 -0700
To: WebAudio/web-audio-api <web-audio-api@noreply.github.com>
Message-ID: <WebAudio/web-audio-api/issues/131/24244415@github.com>
> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17335#5) by Marcus Geelnard (Opera) on W3C Bugzilla. Thu, 06 Dec 2012 08:38:35 GMT

(In reply to [comment #5](#issuecomment-24244407))
> 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.

Reply to this email directly or view it on GitHub:
Received on Wednesday, 11 September 2013 14:35:59 UTC

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