[Bug 17366] (OscillatorTypes): Oscillator types are not defined

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17366

Chris Wilson <cwilso@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cwilso@gmail.com

--- Comment #5 from Chris Wilson <cwilso@gmail.com> ---

(In reply to comment #4)
> Paul, I think that specifying the amplitude (i.e. time-domain signal) the
> way you suggest requires that an implementation does not deal with frequency
> folding.
> 
> An important point of the oscillator node is that it is capable of producing
> a high quality signal without folding effects. For instance, this requires
> that the signal is allowed to have ripples (for every wave type except the
> sine).

Yes.  It would be a definite quality hit if we were to do this as per this
suggestion.  Chris (Rogers) spent a ton of time on the anti-aliasing in
Webkit/Blink's oscillators; I would not want to lose that.  We can specify it
in one particular method (e.g. what webkit and blink do), we can enable
options, specify either the mathematical one or a single precise implementation
is allowed, or we can define the math and say the actual implementation should
approximate this but may improve upon it.  Not there was another bug about
this, and Chris added text on in quite a while ago -
http://www.w3.org/2011/audio/track/issues/85?changelog.

> I agree that we need to specify:
> 
> - The phase of the signal (and it should be consistent between wave forms).
> - The signal strength (RMS, or something else).

Yes to both of these.  Note that apparently triangle's phase is apparently less
standardized, but I agree that the phase in our current implementation looks
like a bad choice.  I think the current phase is off by PI/2, though, in order
to be consistent with other waveforms?

On RMS - I'm not convinced RMS is a good idea, because I use oscillators to
move between values all the time, and I'd want a predictable value.  Perhaps it
would be best to consistently duck by some amount?  IIRC, Chris' implementation
initially had oscillators go between -0.5 and 0.5, not sure what thought
process led to him changing to -1 to 1 with some ducking.

Without looking at the code, I think we may be ducking sawtooth waves as well
(since they, too, may clip).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Tuesday, 3 September 2013 19:27:02 UTC