shouldn’t that be rack::simd::float_4(.999f)?
2 Likes
I remember running into this and similar to Squinky found float/double made a difference. However in the end I think I settled for a higher frequency cutoff like 22Hz and things behaved at that value. Depends on your application of course, but 2 Hz might be lower than it needs to be.
1 Like
The issue is, it works just fine on some machines, and not at all on others.
But just in case, for the 3rd test version (code above), I converted to using double for the filter, just in case. And it still kills the code on some machines. Well, something kills the code - I am pretty sure the problem is not in the filter code itself. That version I think has an effective cutoff somewhere around 30Hz, just by empirical measurements.
Also, the current version I am using has a much higher cutoff (too high if you ask me). But it seems to be working for Omri, and I need to find out if it works for the general population.
Those filter coefficients are awfully small. I really think asking a 32 bit biquad to do arithmetic with those coefficients is pretty risky. some of the coefficients are like 2*10-8, and some are like 1 or 2. But it the bug is just some memory smasher unrelated to the filters that’s certainly possible.
Yes, I am no longer using the biquad filter, so a non-issue at this point.