Hi folks, I am currently rewriting my RC-Filters ... and I ran into some "core"-trouble ...
Digital IIR-filters are (at low cutoff-frequencies) numericaly unstable. You can test this by using lmms standard-lowpass and esp. the standard-highpass and sweep it at very low frequencies. You even can trigger that unstable behaviour better (or more precisely make it extremely worse...) by exporting such a track to 192kHz, 8time oversampled (this is just because of the fact, that the relative cutoff-frequency gets even lower by this...). If only considering a one-pole-no-zero-filter (passive RC) the only effect is that you can not reach your desired cutoff-frequency. If it's a one-pole-one-zero/one-pole-two-zeros (lmms-standard-filters: lowpass, highpass, bandpass-csg/cpzg) this renders the low-end of frequencies unusable, because the filter will produce all sorts of nasty output and/or even will clip or saturate wildly. For a two-pole/two-zeros-approach (typical active RC-filter) it becomes even worse... The standard-way arround these problems is (if a DSP can handle such numbers) to use 64bit-double-precision floats (or better) for the filter-coefficients as well as for the samples in the filter-history. While it's trivial to change the filter-coeffs to doubles (as modern machines do all fp-stuff in doubles and just cast to floats afterwards this should even give a little speed-boost) in ./includes/basic_filters.h, I wonder what would be needed to do the same for the internal sample-format... I see that ./include/lmms_basics.h defines this: > typedef float sample_t; // standard sample-type But if I just change it, I get a bunch of compiler-errors for "sample_buffer.cpp" due to hard-coded floats instead of sampe_t's ... Just in case I fix that, what other "happy" side-effects would the change of sample_t from float to double imply? regards, Stefan ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ LMMS-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmms-devel
