Re: [Bug 21980] New: WaveTable is highly underspecified

Den 2013-05-09 20:57:00 skrev Chris Rogers <crogers@google.com>:

>
>
>
> On Thu, May 9, 2013 at 7:26 AM, Ehsan Akhgari <ehsan.akhgari@gmail.com>  
> wrote:
>> On Wed, May 8, 2013 at 11:54 PM, Chris Rogers <crogers@google.com>  
>> wrote:
>>>
>>>
>>>
>>> On Wed, May 8, 2013 at 8:46 PM, <rbj@audioimagination.com> wrote:
>>>>
>>>>
>>>> it seems to me that if the createWaveTable() method is, essentially,  
>>>> an inverse DFT.  is it anything else?
>>> That's the basic idea, but then this time-domain version has to be  
>>> sampled at many different rates, so we want to avoid aliasing. >>> In  
>>> WebKit (Blink is the same) we use a multi-table approach (similar to  
>>> mipmaps for graphics) where each table uses an inverse >>>DFT, culling  
>>> out an appropriate number of aliasing harmonics.  Then when we render  
>>> the waveform, we select which two adjacent >>>tables to use,  
>>> interpolate between those two, and then use linear interpolation...
>>> https://svn.webkit.org/repository/webkit/trunk/Source/WebCore/Modules/webaudio/WaveTable.cpp
>>> https://svn.webkit.org/repository/webkit/trunk/Source/WebCore/Modules/webaudio/OscillatorNode.cpp
>>>
>>> We have tests where we load up a WaveTable and use it with an  
>>> OscillatorNode, sweeping the frequency from very low to high  
>>> >>>(something like 10Hz -> 20KHz), checking that the aliasing isn't  
>>> too bad...
>>
>> That is my point.  :-)  It should be possible to implement WaveTable  
>> (and OscillatorNode) without linking to the WebKit >>implementation!
>
> But I think the spec is very detailed and quite clear on what the  
> WaveTable and OscillatorNode should do mathematically.  It doesn't  
> >dictate a specific technique for achieving the effect.  I only  
> mentioned the WebKit code here as one possible practical approach.

Well, the spec is fairly clear about what data you provide to the  
WaveTable (perhaps the language can be improved as suggested by others).  
On the other hand it's not very clear what the output from the node should  
be (I think we've had this discussion before). There are so many ways to  
implement this, e.g:

* On-the-fly sum-of-sines generation with perfect anti-aliasing (i.e. skip  
frequencies above Nyquist on a per-sample basis).
* Bi-linear interpolation in pre-generated time-domain "mip-maps" (i.e.  
the WebKit/Blink way).
* Linear interpolation into an IDFT version of the table at 4x the sample  
rate followed by a down-sampling lowpass filter (i.e. 4x oversampling).
* Nearest interpolation into an IDFT version of the table.

...these methods result in completely different output waveforms and  
different sound quality, meaning that:

* It's difficult to create any meaningful tests for the Oscillator node.
* Different clients may produce quite different results.
* A web-developer can not rely too much on the output of the Oscillator  
node.

As it currently stands, I'd personally prefer making a custom oscillator  
node (using a script processor node) if I was to make a music synth for  
instance, since that'd give me consistent behavior across clients.

My point being this: I think we should be more strict in the spec. If we  
do not mandate a specific algorithm, at least we should provide some sort  
of "lower bound" to what is an acceptable implementation (the latter is  
obviously more difficult to get right).

/Marcus