Denormals in the de-zipper

Zynewave · 31 Mar 2008

infuzion wrote: I did a bit more hacking on malc's ASM de-zipper.

Thanks for your efforts. I know malc is still working on the de-zipper. I got an email from him, where he presented the excellent idea that the hop should be kept constant, and only the glide period should be varied in 128 sample steps, to compensate for the different sample rates. That's sufficiently precise.

Here's a part of my reply to him:

My main concern was the factor 2 involved with 88.2/96 kHz double samplerates. While we're at it: Why not adjust the glide periods so that it is closer to a more sensible value such as 50 ms. Looks nicer if you want to write the glide time in the component reference pdf. That results in 2176 for 44.1 (49.3ms) and 2432 for 48.0 (50.7 ms).

I've also done some thinking on the de-zipper code. It struck me that the step calculation can become inaccurate for larger glide periods, due to the limited float precision. This means that the gliding can over/undershoot the target value. So, since the divide is performed in each hop block anyway I figured it could just as well recalc a more precise step value based on the decreasing glide period. It turned out to be a simpler and more efficient implementation, involving fewer compares. I was kicking myself for not having thought of this solution from the beginning:

streamin in; streamin glidePeriodPlus128; streamout out; float cnt = 0; float in1, step;

hop(128) { // Use max(,1) to avoid runaway cnt and division by zero in step calc. cnt = max(cnt - 128 + (in1 != in)&(cnt>0)&(glidePeriodPlus128-cnt), 1); step = (cnt>1)&((in - out) / cnt); // Copy in to out when not stepping, to compensate // for any rounding errors in step additions. out = (step!=0)&out + (step==0)∈

in1 = in; }

out = out + step;

aliasant · 31 Mar 2008

Infuzion said: Could someone please double-check the output values?

I checked and it seems to output the values correct.

I also checked with a frequency graph on all the different DeZip versions and they all shows up on the low end..... except Zynewaves new thing.

This one looks like something else.

Edit: Looking at Zynewaves new thing I noticed that the glideperiod needs to get up above 1024. Then it starts to sound good.

Zynewave · 31 Mar 2008

aliasant wrote: Edit: Looking at Zynewaves new thing I noticed that the glideperiod needs to get up above 1024. Then it starts to sound good.

You need to set the glideperiod input to 2048+128 to make it behave like the earlier de-zipper versions.

aliasant · 31 Mar 2008

Zynewave wrote: aliasant wrote: Edit: Looking at Zynewaves new thing I noticed that the glideperiod needs to get up above 1024. Then it starts to sound good.

You need to set the glideperiod input to 2048+128 to make it behave like the earlier de-zipper versions.

Yes. I see that now. Cool. Experimenting with it. Sending a LF squarewave thru it and other stupid things =)

infuzion · 31 Mar 2008

Zynewave wrote: It struck me that the step calculation can become inaccurate for larger glide periods, due to the limited float precision. ...I was kicking myself for not having thought of this solution from the beginning:

"limited float precision"... is that another vote for SSE2? 😉 Sometimes it takes a while for me to figure out the best (often simplest) solution. :/

aliasant wrote: Infuzion said: Could someone please double-check the output values?

I checked and it seems to output the values correct. I also checked with a frequency graph on all the different DeZip versions and they all shows up on the low end..... except Zynewaves new thing.

Thanks fro the help aliasant... is malc's/mine act like a filter?

aliasant · 31 Mar 2008

This is me running a 1kHz Saw thru the dezipper so yes. It acts like a filter of some kind.

Andrew J · 31 Mar 2008

Well that is what a de-zipper is for! You filter out higher frequencies so that you don't have big/fast changes (i.e. pops).

oddson · 1 Apr 2008

Here's one way to smooth and still avoid denormals but it won't work on data with a broad range of scale:

streamin x; streamout y;

hop(32){ y = y + ((x<y & -2) + 1) * 0.001; }

It moves in set step sizes and therefore avoids denormal multiplication.

It may not be appropriate for the default dezipper code because of the scale problem but if you work only with normalized parameters it might be right for someone with dozens of dezippers in their projects (and you could pick your own hop and delta values).

The existing timer mechanism could still be used to flip to the exact value after the code has got you into the ballpark.

malc · 1 Apr 2008

So based on Frits' great idea of using a fixed glide time and the code he presented earlier, here's what IMHO looks to be a good candidate for the dezipper primitive: Download Latest Dezipper

The code is here. If you fancy waving your magic wand over it infuzion please do.

streamin in; streamin glidePeriodPlus128; streamout out;

float cnt=0; float in1=0; float step=0; float F0=0; float F1=1; float F128=128;

// Only calculate step every 128 samples mov eax,ecx; and eax,127; cmp eax,0; jnz endCalcStep;

// Calculate cnt movaps xmm0,cnt; movaps xmm2,xmm0; movaps xmm3,xmm0; subps xmm0,F128;

movaps xmm1,in1; cmpps xmm1,in,4; cmpps xmm2,F0,6; andps xmm1,xmm2;

movaps xmm2,glidePeriodPlus128; subps xmm2,xmm3; andps xmm1,xmm2; addps xmm0,xmm1; maxps xmm0,F1; movaps cnt,xmm0;

// Calculate step movaps xmm3,xmm0; cmpps xmm0,F1,6; movaps xmm1,in; subps xmm1,out; movaps xmm2,xmm1; divps xmm2,xmm3; andps xmm0,xmm2; movaps step,xmm0;

// Calculate out movaps xmm2,xmm0; cmpps xmm0,F0,4; andps xmm0,out; cmpps xmm2,F0,0; andps xmm2,in; addps xmm0,xmm2; movaps out,xmm0;

// Remember previous in movaps xmm0,in; movaps in1,xmm0;

endCalcStep:

// Add step movaps xmm0,out; addps xmm0,step; movaps out,xmm0;

The glidePeriodPlus128 input is calculated in a green module by using sample rate and a fixed (but user defineable) glide period in millisecs.

Zynewave · 1 Apr 2008

malc wrote: The glidePeriodPlus128 input is calculated in a green module by using sample rate and a fixed (but user defineable) glide period in millisecs.

I've already notified malc by email: There's a small bug in the green module. It should add 128 to the final int output, due to the way that "cnt" is calculated in the code.

infuzion · 2 Apr 2008

Zynewave wrote: malc wrote: The glidePeriodPlus128 input is calculated in a green module by using sample rate and a fixed (but user defineable) glide period in millisecs.

I've already notified malc by email: There's a small bug in the green module. It should add 128 to the final int output, due to the way that "cnt" is calculated in the code.

Yea, I was wondering where the +128 of the glidePeriodPlus128 went to? 🙂

Might be a day or 2 before I can really study this; I just got a 20% pay cut, so I think I'll job-hunt in the morning rather than SM-hack; depends how early I can wake up.

infuzion · 2 Apr 2008

malc wrote: The code is here. If you fancy waving your magic wand over it infuzion please do.

OK, I couldn't sleep... so here it is: http://shup.com/Shup/33660/new-dezipper ... _saved.osm

streamin in;streamout out; streamin glidePeriodPlus128; float cnt=0;float in1=0;float step=0; float F0=0;float F1=1;float F128=128; movaps xmm7,out; //hop(128) mov eax,ecx;and eax,127;cmp eax,0;jnz endCalcStep; // Calculate cnt movaps xmm0,cnt; movaps xmm2,xmm0; movaps xmm3,xmm0; subps xmm0,F128; movaps xmm6,in;

movaps xmm1,in1; cmpps xmm1,xmm6,4; movaps xmm4,glidePeriodPlus128; cmpps xmm2,F0,6; subps xmm4,xmm3; andps xmm1,xmm2;

andps xmm1,xmm4; addps xmm0,xmm1; maxps xmm0,F1; movaps cnt,xmm0;

// Calculate step movaps xmm3,xmm0; cmpps xmm0,F1,6; movaps xmm4,xmm6; subps xmm6,xmm7; //in-out movaps xmm2,xmm6; divps xmm2,xmm3; andps xmm0,xmm2; movaps step,xmm0;

// Calculate out movaps xmm2,xmm0; cmpps xmm0,F0,4; andps xmm7,xmm0; cmpps xmm2,F0,0; andps xmm2,xmm4; addps xmm7,xmm2; movaps out,xmm7;

// Remember previous in // movaps xmm4,in; movaps in1,xmm4;

endCalcStep:

// Add step //movaps xmm7,out before hop addps xmm7,step; movaps out,xmm7; I commented out a few commands so you know we don't need them. Considering the hop, I saved an average of 0.0625 cycles!! Without the hop, it would have been about 8 cycle-savings on both my AMD64 & C2D, which is decent. Most of that savings is from pre-loading in & out values in a xmm & using that xmm. Using an xmm for F0 (=0) was slower.

I added the 128 in the green, & did a tad of primitive reduction there.... I don't think using a Int in a Float Divide would matter speed wise for a call-once-on-load routine?

If someone can test output please? 😇 (remember malc's may not have the green +128 just before output)

malc · 2 Apr 2008

Works well here inf, thanks for looking at it!

I completely forgot to add the 128 after Zynewave pointed it out 😊

Well I think I can make a primitive from this now. If anyone finds any other issues let me know.

Thanks to everyone - top effort!

Zynewave · 2 Apr 2008

infuzion wrote: If someone can test output please? 😇 (remember malc's may not have the green +128 just before output)

Works fine here. Thanks.

I think this thing is ready for mass production!