Dissecting sawAA

Dissecting the sawAA. I came accross this algorithm which I don't really understand but I guess it's what makes the saw Anti Aliased, can somebody (Master Davies?) point me in the right direction in understanding it?

Thanx in advance.

This is what I've understand so far.

The saw macro has 2 inputs. ph (the phase) and |i| (the absolute value of the increment level).

1 is subtracted by |i| and ph is the compared to the result of this subtraction. If ph is > (on the positieve side (a)) or ph is < (on the negatieve side (b)) this subtraction goes thru and triggers one of the following calculation. Else ph is output.

a. ((((1-|i|) - ph)/|i|) * |(((1-|i|) - ph)/|i|)|) + ph
b. ((((|i|-1) - ph)/|i|) * |(((|i|-1) - ph)/|i|)|) + ph

 

From looking at the oscilliscope, I can guess what this module is trying to do, although I can't quite fathom the exact details. My guess is that the two equations generate equations of lines -- one for the rising edge of the saw, and another not-quite-vertical line for the falling edge.

When you generate a saw wave digitally, using the naive approach (a ramp followed by an abrupt drop) there are two main causes of aliasing.

The first is that the falling edge of the ideal saw wave gets quantized to a specific sample. If the length of the saw is supposed to be 32.41 samples, then -- if the falling edge is abrupt, what you actually get is saw waveforms of either 32 samples or 33 samples, and you can actually see the effects of this on a scope. For very high frequencies, you can probably hear the two different tones separately.

This module appears to try to compensate for this effect by adding a slightly more gentle slope to the falling edge of the wave: one line segment going up, and one line segment with a steep (but not infinite) slope on the falling edge. You can see an intermediate sample on the falling edge of the waveform between the maximum and minimum values.

Unfortunately, there's another source of aliased harmonics in a saw wave. The sharp corners at the top and bottom of the saw generate an infinite train of decreasing harmonics in the ideal signal (the continuous waveform that's being modelled here), and these harmonics generate aliases when we convert it to discrete samples.

If you drop a frequency analyzer on the output of this module, you will see that -- in fact -- it doesn't really do a very good job of anti-aliasing. You will see a train of real harmonics of decreasing amplitude going from right to left, and a clearly visible train of aliases reflected at the nyquist frequency that go from right to left. These aliased harmonics are not only audible, but are also inharmonic (not even multiples of the fundamental frequency), so the results are fairly unpleasant.

The exact implementation seems to be: a linear (ph) most of the time, and a steep quadratic equation for the falling edge. So you could argue, I suppose, that the falling edge isn't straight. But still, there's no way that the slight non-linearity of the falling edge will eliminate the aliases due to sharp edges on the wave-form. Proper filtering of harmonics above the nyquist frequency would produce an effect that extends all the way through the straight segment of the waveform.

So. The bad news, simply put: this macro doesn't actually generate a an anti-aliased waveform. It does, I suppose, generate an anti-aliased waveform in a graphical kind of sense; but the issue is audio aliasing, not graphical aliasing. (see the attached output of this macro on a spectroscope).

 

Thanx for the great explication.

I'm surprised that such a "bad macro" is used in a lot of recent Reaktor ensembles (i.e. 2OSC and in core macros MultiWvs) to demonstrate the power of core.

cheers

 

AW: Re: Dissecting sawAA

yes you are right (nevertheless the mathematical analyze is very interesting) but i think the sense of "anti-alaising" is not "no-alaising" but "lower-alaising".
Perhaps you could show a screenshot of the frequency analyze of the same oscillator without the saw AA - macro. It would be interesting to see whether the AA-macro has a great effect.

ciao herw

 

Good point. Yes, as it turns out, SawAA is significantly better than a raw digital Sawtooth. The digitial sawtooth (with a hard quantized falling edge) really is nasty, and the split tones are definitely audible.

Here's screenshots of spectra for SawAA, Digital Sawtooth (hard edge), and my Full-Antialiased macros. (sawcomparison.gif). The note is D''. That's high enough to ensure that the individual harmonics and aliases are clearly and seperately visible. Lower notes are affected too, but the overlap of harmonics makes it less clear what's going on.

An interesting observation, though. SawAA does seem to have significantly less high-frequency content than it should. Testers commented on this when comparing SawAA and the "Fully-Antialiased" macros, saying that "Fully-Antiased" sounded brighter. (spectralcomp.gif). By rough measurement, high frequencies in the SawAA macro seem to be down about 10db from what they should be. (The note is midle C, I believe). By inspection, I believe that the "Fully-Antialiased" spectrum is correct. The curve *should* be something along the lines of log(1/n) across the entire spectrum --- which should continue to level off in high frequencies. Truthfully, the "Fully-Antialiased" waveform will be slightly off from ideal results, due to the use of a non-ideal integrator. I can't say how much. As a rough check, the correct spectrum should be similar to that of Digital Sawtooth, but with the aliases removed. (It is).

The spectrum exhibited by SawAA suggests a possible derivation for the formulae used by the macros. If I had to guess, I would guess that the SawAA macro is derived by applying a two zero low-pass (or some equivalent low-order FIR filter) to the ideal waveform, based on the observation that the SawAA spectrum is close to log-linear from about 8khz and up. At a first approximation, from visual inspection, SawAA may be a sawtooth with a two-zero lowpass filter, Fc of ~11.025khz(?), applied *before* the waveform is sampled. Defnitely a clever approach. Or, another equivalent guess: a polynomial interpolation of Saw(sample), Saw(Sample+1/2), Saw(Sample+1/3). (where Saw is an ideal sawtooth). Roughly equivalent to a 2nd-order FIR filter in frequency response.

The primary level sawtooth is also interesting. The waveform is slightly different from SawAA. It seems to be a minor variant of SawAA. It has a distinctly visible ringing on the falling edge of the wave, with a more or less constant slope on the rising edge. But the spectrum looks more-or-less the same. I didn't dig deeper into the primary level macro, but it *might* have better high-frequency response. The riginging on the falling edge suggest that an analog of a 2nd-order IIR filter is being used. Possibly, oversampled, filtered, and decimated.

I have also attached the upgrded test harness, for those who are interested in playing. (sawanalysis.zip).

Interesting stuff.

 

Hard to tell, but the primary level macro probably has very slightly better high-frequency response, with equivalent aliasing.

 

AW: Re: Dissecting sawAA

thanks for uploading the test file; interesting.

ciao herw

 

Yeah, really interesting.

Thanx

 

Hey,

This Anti Aliasing scheme in SawAA is a parabolic 3 point interpolation. it generates 2 points over a S curve in during the transition. It is quite a bit better, generates less zipper noise, than linear interpolation( generating 1 point between 2 points).

The Reaktor Classic Primary Level Saw is quite simular but has a 1 pole Hi Boost EQ at the end...

-Martijn-

 

Code:

___
>---------|   |                    ___
          | * |-------------------|   |
  1.20627-|___|\  ______          | + |------>
                \|      |   ___  /|___|
                 | z^-1 |--|   |/
                 |______|  | * |
                   -0.171--|___|

 

Oowell, sofar for asci art in this forum hehe

 

Is the 'sawAA' you guys are discussing just the non-core saw osc in reaktor 5 ?
does the Saw Sync use the same interpolation approach ?

I spent some time building a minBlep osc, I got as far as a rough working model (some clicks and DC drift at high frequencies)... anyhow, when I A/Bd it with the built in Saw Sync osc, I found that I couldn't hear enough of a difference (basically none) to make the extra cpu worthwhile. I then compared the Saw Sync to Robins Blit Saw osc and in a listening test I again didn't hear enough of a difference...
I had a look at the spectum and sure enough the aliasing is worse with the built in Saw Sync, but its at such a high frequency that it seems like NI made a good compromise ?
What applications would require better anti-aliasing than the Reaktor5 built-in sync oscs ?

(possibly my headphones/ears are not good enough for the comparison - I will blast it through my monitors when I have the house to myself)

cheers

Col

 

SawAA is, I believe, a core oscillator lifted from 2osc. (?) It's core. I'm not dead certain where it came from.

Seeing things in context, I have to admit, SawAA (and the primary level macro) are decent compromises. Understanding what they are, and how they work (and the tradeoffs involved).

Can I hear the difference? Yes. Although it is subtle, I admit. I can hear a very slight metallic high-frequency ringing in the SawAA. And I can hear the aliases more clearly if I sweep the oscillator frequency slightly. The aliased harmonics move in the wrong direction when the oscillator is swept, and I can hear them going down when they should be going up (or vice versa). Still subtle. But more noticeable.

Enough to make up for the extra CPU hit? I don't know.

wrt/ performance. I really need to take another kick at my macros. Knowing what I now know about peformance of misaligned doubles in Reaktor, I might be able to do something about the current performance. It *should* run fairly fast and light (it does in C++). At the time I built them I didn't know there was a huge penaulty for use of doubles. Definitely not as fast as SawAA. But performance could definitely be improved.

 

Interesting posts as usual, I enjoy these threads. What did you find out about performance effects of misaligned doubles? How do you misalign (or correctly align, for that matter) doubles in core?

Regards, manuel

 

> performanc hit for doubles.

Unfortunately, you fix misaligned doubles by fixing the core compiler.

See here: http://www.native-instruments.com/forum_us/showthread.php?t=45829

and here:
http://www.native-instruments.com/forum_us/showthread.php?t=45826

Unfortunately, the lesson learned is: don't use 64-bit floats in this version of reaktor in audio-rate structures. I've used 64-bit floats quite a bit in some of my structures, and I need to go back and re-evaluate.

 

i think you are right. it was created by martijn deluze, who posted above (thats martijn zwartes, who i believe made the corecell and 2-OSC).

 

Yes it was lifted from 2-OSC and is also to be found in core standard macro -> oscillator -> 4-Wave Mst and 4-Wave Slv.

Again Thanx guys for the explication.

cheers

 

I did get the impression we were in the presence of nobility.

Thanks, martijn, for reponding.

 

Robin, slightly offtopic, but, as a sort of 'intermediate' builder with little knowledge of dsp I was wondering - can filters be antialiased? Should they be? If using your antialiased osc's, will a primary or core filter introduce aliasing anyway? Or does aliasing only occur in the osc?

 

(trying to think whether I've repeated the mantra recently...)

Just in case.

I am an expert programmer; I am far from an expert DSP guy. Most good undergrad electrical engineers could probably put me to shame. So take most of what I say with an appropriate degree of caution. At best, I'm an intermediate dsp guy.

A lot of a little bit of knowledge is a lot of a dangerous thing.

Anyway. Back to the question.

No, I don't think so. Filters are "linear" operations; and linear operations on sampled signals don't introduce new harmonics (although they can affect the amplitude of existing harmonics). Filtering a signal without aliases will not introduce new aliases. Nor will any other linear operation (combinations of additions, subtractions, delays).

It's the non-linear operations that you have to watch out for: waveshaping, FM, AM, applying envelopes, (many others, I'm sure). Probably pretty much everyting *except* adding, subtracting, delaying by a fixed delay, and filtering will generate extra harmonics, and if those extra harmonics happen to fall above the nyquist limit, then you will get an aliased harmonic.

One of the strategies for dealing with aliasing generated by non-linear operations is to upconvert the sample rate of the signal, perform an operation that would have generated unacceptable harmonics at the original sample rate, filter to remove the unacceptable harmonics, and then downsample again. But that presumes that you are going to do something non-linear at the higher sample rate. And it also depends on whether the non-linear operation is going to produce acceptable aliasing at the higher frequency. More often than not, the upsample/downsample strategy fails because there's unacceptable aliasing even at the upsampled frequency.

In theory, (and in practice with almost dead certainty) upsample->filter->downsample is equivalent to a (somewhat baroquely complicated) filter at the original frequency. For the sme amount of work, you could almost definitely build a better/flatter/steeper/cheaper/faster filter at the original frequency, if you are not going to do anything interesting at the upsampled sample-rate.