Page 3 of 3
Re: Oversampling Toolkit (Revisited)
Posted: Mon Dec 22, 2014 8:15 pm
by martinvicanek
Wow, you are a genius, Tronic!

Pity I haven't time right now to check it out in depth.
Re: Oversampling Toolkit (Revisited)
Posted: Tue Dec 23, 2014 2:01 pm
by Tronic
martin're too kind
I just port the implementation of Laurent de Soras, in language more friendly, like Ruby.
Re: Oversampling Toolkit (Revisited)
Posted: Wed Dec 24, 2014 9:02 am
by MyCo
Thanks Tronic, the coeffs are indeed generated by this code. You can reproduce them with transition = 0.01 (hard slope) and 0.05 (soft slope).
Re: Oversampling Toolkit (Revisited)
Posted: Tue Apr 07, 2015 1:33 am
by TheOm
Thank you very much for sharing these.
I am currently using the Order 10 hard slope version in a project (a distortion plugin).
During optimizing I first changed the upsampler to do the filtering for odd and even samples simultaneously, because I only have a stereo input signal.
When I wanted to do the same thing for the downsampler I was a bit surprised to see that the downsampler does twice the amount of work that the upsampler does, which seemed strange to me. So I looked closer and it seems like f2outEven and f1outOdd are calculated, but never actually used.
When I removed those calculations I could not notice any kind of change in behaviour, so I think they really are superfluous.
Also another thing that I noticed while testing:
Changing from not oversampled to x2 oversampled reduces aliasing by a fair amount.
But I could not see any difference between x2 and x4 upsampling. Why is that?
Re: Oversampling Toolkit (Revisited)
Posted: Tue Apr 07, 2015 6:51 pm
by MyCo
TheOm wrote:So I looked closer and it seems like f2outEven and f1outOdd are calculated, but never actually used.
That's not true. Those variables are used in a loop. So on the next sample they are read before they get overridden. And their values are at the end used to calculate the interpolated final output ("out") by using their corresponding xmm registers.
TheOm wrote:When I removed those calculations I could not notice any kind of change in behaviour, so I think they really are superfluous.
You actually didn't remove em, you just shuffled them to different SSE channels and at the end you shuffle them back and interpolate. That's not surprising me, it's actually how you would do it when you don't rely on all 4 channels. Martin mentioned that as well earlier:
MyCo wrote:martinvicanek wrote:You could exploit SSE to squeeze out still more (unless you really need to process all 4 channels in parallel)
I didn't want to go that way, because I thought about using it for oscillators in a poly section.
TheOm wrote:But I could not see any difference between x2 and x4 upsampling. Why is that?
Yeah, the problem is, it hardly depends on the aliasing your code is generating. When you take the rate reducer example in this thread, you can clearly see the difference. The higher oversampling order only makes sense when you have aliasing above twice the sampling rate (4 times the nyquist).
Re: Oversampling Toolkit (Revisited)
Posted: Tue Apr 07, 2015 8:38 pm
by TheOm
This is the usage of the channels in xmm0 in my version of the downsampler:
xmm0[0]: Filter1, Even, Left
xmm0[1]: Filter1, Even, Right
xmm0[2]: Filter2, Odd, Left
xmm0[3]: Filter2, Odd, Right
Notice that I am neither calculating Filter 2 for the Even Samples nor Filter 1 for the Odd samples, but the output is still identical to your original version.
It's also pretty easy to see in the blue code version that f2outEven and f1outOdd do not contribute anything to the output.
Re: Oversampling Toolkit (Revisited)
Posted: Tue Apr 07, 2015 10:02 pm
by MyCo
Yeah, something is messed up there. Not sure if I just forgotten to remove that when optimizing the code, or if the filters should actually be joined and I made a mistake.
Re: Oversampling Toolkit (Revisited)
Posted: Fri Apr 17, 2015 3:00 am
by MyCo
I've updated the kit. So the unused code is removed. Download is in the first post.