Refactor `BiquadFilterNode`

[b-ma]

trafficstars

Hey,

Quite a big refactoring here:

• simplified all the code
• implemented tail-time (#34) and actively processing (#147, TBC)
• added tests against frequency responses gathered from Chrome and Firefox
• support for multi-channel
• get_frequency_response does not rely anymore on communication between control and render threads

Performance wise:

• There is finally no huge visible difference in the benchmark (cf. Substractive Synth), at the exception that it is now stereo by default while, as far as I can tell, it was only mono before, so performances of the processing itself are better. This could be improved back with #117.
• Also all the internal computations are done using f64, maybe this could be moved to f32 but then the tests against Chrome / Firefox (which internally use f46) frequency responses get wrong at some places due to floating point errors. This is something we have to decide I guess, maybe now that we are sure the coefficients and frequency response are good, we could switch back to f32 and compare against our own values to prevent regression, but maybe that's not a good idea, I don't really know. Any idea on that?

Cheers,

[orottier]

Very nice, the previous implementation could definitely use some more concise and well-organized methods. I need some more time for the reviews, hopefully tomorrow!

[b-ma]

is more concise and fine for small scoped imports for me

Just removed the import altogether

Clamping inside the loop saves an allocation (to_owned)

Nice catch!

I think my version is a bit more clear and better for cache lines

Just replaced all with any because the filter has to continue the processing if any value in the history is not 0, but it's more clean yep!

I think x1, x2, y1 and y2 are maybe more performant as [f32; RENDER_QUANTUM_SIZE]

Yup maybe, but I'm afraid it will add a lot of code to keep things clean when the channel number change, instead of just self.x1.resize(num_channels, 0.);. Actually I have an idea I'd like to test about the note I left on the clean handling of channel number change, maybe let's reconsider that at this moment?