On Wed, Apr 27, 2016 at 6:35 PM, Karl Tomlinson <[email protected]> wrote:
> 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. > > Thanks for your comments Karl! To be honest, I'm not sure how useful IIRFilterNodes will be in practice. One could argue that we should see how widely the blink implementation is used "in the wild" before we implement it ourselves.In this case, my plan was to import the blink IIRFilter as utility code as we've done in the past, so I don't think supporting the IIRFilterNode will cost us much time or effort and keeps us compatible with the spec. > 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? > > We're using doubles rather than floats, but I'm not sure if this is sufficient to avoid numerical problems with higher order filters. > 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? > The discussion in https://github.com/WebAudio/web-audio-api/issues/323 ruled this out because it seemed of limited utility and could be challenging to implement. We should work to make sure that automation does not sneak in. I think it might make sense to raise your concerns as issues against the Web Audio spec. I'm sure you'll get more informed feedback than I can provide :) Dan _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
