Site navigation

DSP Filters

General JUCE discussion
#1

I am using Vinnies dsp filters on a project.  They work great on windows (32 bit).  But when I build for linux (64 bit), the filters add very bad artifacts to the audio.  The artifacts get much worse as tne filter gain is increased, and when the filters are bypassed the artifacts are gone.

I don't know if there is a problem with them on linux or if it is a 64 bit issue.  I wanted to try 64 bit windows, but I don't have a 64 windows install.  I also wanted to try 32 bit on linux, but I have been unable to compile 32 bit on my kxstudio install. (missing headers and have not been able to get the right ones installed).

Any body know of a problem with the filters on linux or 64 bit or 64bit-linux?

 

Thanks.

#2

Since no one responded to obious question now is: "Has anyone else tried the DSPFilters on Ubuntu 64 bit linux?"

#3

I can’t help much here as I haven’t used the DSP filters yet, but it might be that some functions work differently. For example I had some issues due to abs() expecting integers on OS X which lead to a different behavior (using fabs() instead solved it). Have you compared the filter coefficients created on Windows and Linux?

#4

Interesting, in my work to get it working on linux I had a problem with the abs() function too.

I was thinking about the coeffients but had not thought about comparing them to window, but that is a good idea.  I'll try that tonight.

 

Thanks.

#5

Always best to use std::abs, which is templated for all types.

#6

Thanks, I'll remember that next time I neede it.

#7

I set breakpoints in the process method to compare the coefficients on windows and linux and the do match.

 

I wanted to try compiling the dspfilters demo on linux but the linux makefiles are not in the Build directory.  Can anyone point me to a tutorial on the Introjucer?  It is not clear to me how to get it to create a make file for an existing project.

#8

Even if the coefficients do match you may have issues realted to the fact that the floating-point operations are not performed the same way in 32/64b: the default path is SSE for 64b.

Check your compiler options and see if you can reproduce the 64b behaviour with the 32b build!

#9

I'm not sure what you were telling me to here.  I did try several things.

I tried to get the linux binary to build 32 bit, but could not get the libraries needed to link.  When I try to install the 32 bit libraries it tells me to install other libraries but that didn't help.  After a day of fighting it I gave up and moved on.

To confirm 'my' code is functioning correctly, I took biquad.c from MusicDsp.org, created a c++ class to dropin.  A few changes and it was up and running and sounds good. 

 

So I am still wondering what is wrong with the DspFilters on 64 bit linux.  I am looking at this code:

//const double anti_denormal_vsa = 1e-16; // doesn't prevent denormals
//const double anti_denormal_vsa = 0;
const double anti_denormal_vsa = 1e-8;

WIll it normalize different on 64 bit than 32 bit? If it does normalize when it shouldn't, what is the result?  Could my sound problem be due to normalizing?

#10

still trying to figure this out.  I finally got out my oscilloscope to look at the output.  The sound I get from the filters is a buzzing noise at a few hundred Hz.  I guessed it was a spike on buffer boundries so based on 44.1k sample rate and 128 sample count i figured it that would be 344 Hs.  So I put a 345 Hz square wave in and saw a pulse floating across the wave, slightly faster but close,

I think this means the filters are processing a sample or 2 too many or too few in each buffer.  Again, this is in the Filter code because if I bypass them it is clean.  And does not occur on windws 32bit.  I see this on Ubuntu linux 64 bit.

I have been unable so far to figure out what is going wrong here.  Just hoping someone has and idea why this could be happening?

#11

Mystry solved.  The process() code in all the filter types is code like this:

 while (--numSamples >= 0)
        *dest++ = state.process (*dest, *this);
 

I found that the post increment of a pointer on the left side of an assign is compiler dependant.  I changed the code to this:

while (--numSamples >= 0)
    {
        *dest = state.process (*dest, *this);
        dest++;
    }

 

Now it sounds great.

 

#12

Nice find!