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

Re: [web-audio-api] (OscillatorFolding): Oscillator folding considerations (#127)

From: Olivier Thereaux <notifications@github.com>
Date: Wed, 11 Sep 2013 07:29:45 -0700
To: WebAudio/web-audio-api <web-audio-api@noreply.github.com>
Message-ID: <WebAudio/web-audio-api/issues/127/24244371@github.com>
> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17404#3) by Chris Rogers on W3C Bugzilla. Sat, 06 Oct 2012 01:24:02 GMT

(In reply to [comment #3](#issuecomment-24244363))
> Over all, the new text is non-normative, except for the phrasing "care must be
> taken to discard (filter out) the high-frequency information". Here, it is said
> that something must be done, without specifying what must be done.
> At this point, I don't really have a preference for whether we should strive to
> have a common method for synthesizing sound, or allow for variations between
> implementations. However, I think it should be clear what the upper/lower
> quality bound is.
> For instance, if we disregard the anti-aliasing requirement, it would be
> possible for an implementation to simply do an inverse FFT of the wave table as
> a pre-processing step, and then do nearest neighbor interpolation into that
> time-domain signal without any anti-alising or interpolation efforts at all.
> Would that be acceptable?

>From a purist perspective, I don't consider that an acceptable technique for synthesis of high-quality oscillators because it will generate considerable aliasing.  But, I consider it ok for a basic implementation, especially if it's used as a performance optimization for low-end hardware.  Once again, I'd make the analogy with drawing lines.  It's "allowed" for a browser to draw jagged lines, but they might not look so great compared with nicely anti-aliased smooth lines.

I'm happy to share implementation techniques for getting reasonably high-quality oscillators.  In WebKit, the approach we're currently taking is a multi-table approach where we generate a dozen or so tables with successively filtered out partials, then index dynamically into the table appropriate for the instantaneous playback frequency.  We have code to share, or we could discuss the general approach in more technical detail (without code).  In any case, that would be an informative section if we added something to the spec there.

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

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