DSP Robotics Support

Try to create the naive wavetable oscillator (one that directly interpolates values form the array you normally input to wavetable prim) in code component, input the original wave. If it will give the same result as the stock wavetable osc, even with different interpolations, then that means that the frequency is naturally in the wavetable itself.

The peaks go to 16 kHz if you double the WT length. So a 8192 samples WT would accomodate all harmonics for an 8 Hz note. Otherwise you simply run out of samples (and into time aliasing).

In such uncertain cases I would do following: an audible test of it.

1) Record such wave.
2) Scale it down, so that the frequency of interest is in tonal range (8kHz is a little bit too high).
3) Use spectral (FFT) filter to check surrounding spectras, including the one of interest. You may need to play with gain adjustments.

If you can hear audible gain difference in spectral areas of interest in regards to surroundings, then the problem is real, with one "but". In practical terms, the issue may be not signifficant (peak gain versus gain of the rest of the spectra = masking). That's why I suggest using FFT filter for the test.

One of problems I encoutered in the past is the fact, that FFT may cheat. Not always what you see - is what you hear. I guess it depends on FFT resolution vs spectral density vs windowing.

(btw, the spectral analyzer I used - at 128kpts - did not showed anything where you pointed...)

As KG suggested, I tried it with the waveplayer. The result is the same, that means the problem is in the wave itself, not in the code. That's how it looks with the standard waveplayer (linear interpolation):


Making the wavetable bigger is not a solution, because it takes more time to generate the wavetable and also increases the size. The problem would still be there but at lower frequencies. I would rather like to know what is causing this, to fix it for any size of wavetable. I assume it's caused by the highest frequency in the wavetable (from the measurements), and that's why zeroing it get's rid of it. But I have to zero more frequencies to get rid of the imaginary parts in the iFFT as well.

I've done some research on aliasing and sampling and thought about it a little bit more. In situation you are describing what actually happens, is that you are upsampling the wavetable. Interpolation serves as a lowpass filter to ensure the result will have only frequencies below Nyquist.

Problem is the Nyquist frequency itself - Nyquist frequency cannot be properly recorded and reconstructed, because although you can record/reconstruct the frequency itself, you cannot record/reconstruct its phase and amplitude properly.

This schematic demonstrates this. It contains two sine oscillators (made in code). They both are set to Nyquist frequency and theoretically should output wave with the same amplitude and different phase (depending on respective phase settings). Yet, graph shows exact opposite - They both generate wave with same phase, but the amplitude differs depending on the phase. (Note, that phase is initiated on first sample - to change it you have to refresh the schematic)

I believe this is closely related to what's happening here with the wavetable osc. I have no idea how to solve this problem.

Maybe there is something wrong with MAnalyzer... SPAN shows a notch instead of a peak. At least that would make more sense.

I also observed notch with frequency analyzers made in FS (with range boosted to 150dB and fairly large windows)

I bet on analyzer. Consider this. With analyzer - you are using certain FFT resolution and logarithmic view (or - FFT steps don't match peak steps). Which means, that at higher frequencies, peaks from saw - accumulate and are calculated as a sum. Because this is nonlinear process, it should produce quasi peaks and holes, and it will look like a pattern. Graphical data also must be calculated "somehow", so there you have another interpolation set.

It's like observing amplitude modulation of a sine. At low resolution, you have one peak, that behaves strange (fluctuates and gets a sort of hole from time to time), and at high resolution - you have 2 (or 3, depending on AM mode you use) distinct peaks.

I played with analyzer I use a little bit, and at least I noticed, there are places where saw peaks merge, as a result - producing a spectrum that has variated amount of visible peaks in certain spectral areas.

So the first method here would be - to use exported audio signal, rescale it down, and using spectral window - play various ranges of the spectra. 40dB of difference is a huge range in audible levels. The audible distortion would be really nasty.