Daniel Minor writes: > Summary: This provides an alternative to using BiquadFilterNode when > odd-order filters are required or automation is not needed. It is part of > the Web Audio spec and is already implemented in Blink.
Thanks for looking at this, Daniel. I fear that high order filters are going to have problems due to numerical round-off, as pointed out in https://github.com/WebAudio/web-audio-api/issues/323#issuecomment-60545047 Do you know whether that is going to be a general problem or whether many high order filters will be OK in practice? There is some discussion here but my understanding is limited: http://signal.ece.utexas.edu/~arslan/courses/dsp/lecture25.ppt There was some tinkering of test output precision for up to 4th order filters in patch sets 7, 8, 9, and 19 of https://codereview.chromium.org/1361233004/ The Blink implementation doesn't factor into low-order filters, and I expect it would be quite some work to do this. I wonder whether it may be that the IIRFilterNode should be used only for first and second order filters and higher order filters should be composed as a series of these? IIRFilterNode is probably an OK solution for first-order and custom biquad filters, as long as we don't then need a pole/zero filter node with AudioParam parameters because someone wants automation (as already requested for and available with BiquadFilterNode). Then we'd have yet another filter node, which would be unfortunate. Do you think this is likely? _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
