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

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

From: Olivier Thereaux <notifications@github.com>
Date: Wed, 11 Sep 2013 07:28:30 -0700
To: WebAudio/web-audio-api <web-audio-api@noreply.github.com>
Message-ID: <WebAudio/web-audio-api/issues/127@github.com>
> Originally reported on W3C Bugzilla [ISSUE-17404](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17404) Tue, 05 Jun 2012 12:29:45 GMT
> Reported by Michael[tm] Smith
> Assigned to 

Audio-ISSUE-85 (OscillatorFolding): Oscillator folding considerations [Web Audio API]


Raised by: Philip J├Ągenstedt
On product: Web Audio API

It is not defined how the time-domain signal of an oscillator is generated. It would appear that the main reason for WaveTable being defined in the frequency domain is to allow for Nyquist-correct signal synthesis. For example, if the Oscillator frequency is 1000 Hz and the WaveTable has length 4096, the highest frequency component will be 4096 KHz, which could cause folding artifacts.

Depending on how the time-domain signal is generated, the anti-aliasing performed would sound very different.

For example, if the signal is generated in the naive way be looping over the output for each frequency component, one could simply stop before the Nyquist frequency. However, this approach could be very slow.

If nothing is done to prevent folding, the purpose of having a frequency-domain WaveTable at all is questionable.

Finally, should the built-in types (SINE, SQUARE, etc) also be generated using WaveTables internally and be subject to the same folding processing as custom WaveTables?

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

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