W3C home > Mailing lists > Public > public-audio@w3.org > January to March 2012

Re: oscillators and the Web Audio API

From: Joe Berkovitz <joe@noteflight.com>
Date: Wed, 8 Feb 2012 07:49:09 -0800
Message-ID: <CA+ojG-aUfBZR26ZEDBKR-1Guoj0NVxOkbb7oTxG97e10oqBJJg@mail.gmail.com>
To: Alistair MacDonald <al@signedon.com>
Cc: public-audio@w3.org, philburk@mobileer.com
As much as I like the idea of built in high quality oscillators, I am
concerned about scope creep.

Is it possible to take a v1 wavetable-like approach using prefilled buffers
containing various looped waveforms, played at varying playback rates.
instead of algorthmic oscillators?

If this would suffice, it would allow a lot of experimentation with
oscillator waveform characteristics before we have to standardize, which
seems good.
On Feb 8, 2012 9:31 AM, "Alistair MacDonald" <al@signedon.com> wrote:

> Agree with Phil on noise sources. A basic building block of drums and
> percussion needed for most drum sounds, and could be very useful
> generating water, engine and voice sounds in games too.
>
> On Tue, Feb 7, 2012 at 8:34 PM, Phil Burk <philburk@mobileer.com> wrote:
> > Hello Chris,
> >
> >
> > On 2/7/12 12:41 PM, Chris Rogers wrote:
> >>
> >> Up to this point we've relied on AudioBufferSourceNode for general
> >> sample playback, and also periodic waveform playback.  I completely
> >> agree that there are some challenges and limitations to this approach.
> >>  Nevertheless, I've worked on a demo using this approach in my
> >> "wavetable-synth" and have made some initial (although incomplete and
> >> not fully developed) anti-aliased wavetables:
> >> http://chromium.googlecode.com/svn/trunk/samples/audio/lib/wavetable.js
> >
> >
> > Your approach is similar to how I implemented a band-limited sawtooth in
> > JSyn. I used a series of 8 tables, one per octave, filled with increasing
> > numbers of partials. I then interpolate between them depending on
> frequency.
> > I window the partials using a raised cosine to eliminate the Gibbs
> > phenomenon.
> >
> > I also implemented a band-limited sawtooth using a Differentiated
> Parabolic
> > Waveform (DPW) algorithm. It is *much* simpler, is more CPU efficient and
> > sounds almost as good as the multi-wavetable approach.
> >
> > Band limited square and pulse waveforms can be generated from the
> > band-limited sawtooth.
> >
> >
> >> But, back to your proposal.  Having the pure and extremely high-quality
> >> anti-aliased oscillators would be great to have, especially if you have
> >> code to contribute.  Sound quality does matter, so I really appreciate
> >> this.
> >
> >
> > I would be happy to contribute 'C' or Java code to Web Audio API. I'll
> study
> > the code base and then we can talk offline.
> >
> > Regarding sound quality, you can hear how truly terrible the aliasing
> can be
> > in my example JSyn Applet.
> >
> > http://www.softsynth.com/jsyn/examples/tj_seeosc.php
> >
> > Sweep the regular Sawtooth back and forth between 3000 and 9000 Hz. Then
> do
> > the same with the SawBL and SawDPW. Much smoother.
> >
> > If you hear pops and crackles it is due to a bug in JavaSound on Mac.
> >
> >
> >> One thing I'm curious about is how these oscillators can avoid
> >> aliasing when used in FM applications.  It's certainly a goal of mine to
> >> have audio-rate signals modulating AudioParams like .playbackRate or
> >> .frequency
> >
> >
> > Extreme FM using sine waves can produce aliasing. This technique will not
> > prevent that. The problem gets really severe when using non-band-limited
> > sawtooth or square waves to do FM. Yikes! Using band-limited oscillators
> > will certainly help in this case but cannot completely eliminate
> aliasing.
> >
> >
> >> The sine, sawtooth, square, pulse and impulse oscillators are considered
> >> common in computer-music and so would fit into the Web Audio API's
> >> philosophy of implementing common audio building blocks.
> >
> >
> > Noise sources are also pretty fundamental.
> >
> >
> >> I would suggest that the AudioOscillator could have an attribute called
> >> .oscillatorType which could be one of several values.  I would also be
> >> interested in your take on how to implement anti-aliased oscillators
> >> with arbitrary waveforms.  Optimally, the AudioOscillator would be able
> >> to handle more than just the simple waveform types.  I have some ideas
> >> of my own, but we can leave that for later discussion.
> >
> >
> > If the arbitrary waveform is represented by a table then one can generate
> > pre-filtered tables for the higher frequencies. The key is to do the
> > filtering before sampling the wavetable at the high frequency.
> >
> > Phil Burk
> >
> >
>
>
>
> --
> Alistair MacDonald
> SignedOn, Inc - W3C Audio WG
> Boston, MA, (707) 701-3730
> al@signedon.com - http://signedon.com
>
>
Received on Wednesday, 8 February 2012 15:52:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 8 February 2012 15:52:41 GMT