Intent to implement and ship: IIRFilterNode

[Daniel Minor]

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.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1265408

Link to standard:
http://webaudio.github.io/web-audio-api/#the-iirfilternode-interface

Platform coverage: all platforms.

Estimated or target release: Firefox 49

Preference behind which this will be implemented: None.

Support in other engines: Supported in Blink. Not sure about others.

Thanks,

Dan

[Karl Tomlinson]

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?

[rt...@google.com]

On Wednesday, April 27, 2016 at 3:35:54 PM UTC-7, Karl Tomlinson 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.
>
> 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?

I think this will be a problem in practice because people are lazy. They'll find a high-order filter and just plug in the coefficients. There's nothing we can do about that except educate people.

>
> There is some discussion here but my understanding is limited:
> http://signal.ece.utexas.edu/~arslan/courses/dsp/lecture25.ppt

Yes, round-off of the coefficients as well as round-off in the computations is a well-known and well-studied problem. I think we've mitigated many of these by specifying the filter coefficients are double precision and not single. At least that allows implementations to do more accurate computations if needed.

>
> 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/

Yeah, there was a bit of tinkering, mostly in how many digits get printed. IIRC, the actual thresholds didn't change much. (I didn't understand why the same V8 engine printed values differently for essentially the same numbers.)

>
> The Blink implementation doesn't factor into low-order filters, and I expect
> it would be quite some work to do this.

I did consider for a short time the idea of implementing internally the decomposition of the IIRFilter into a set of biquads. But a polynomial root solver isn't that easy (but it is a well-studied problem), and deciding on how to combine the roots together to form biquads is an art. (At least it is in the analog domain where you don't want high Q filters if possible, and the biquads should be combined in a certain order for best results. Not sure if this holds in the digital domain.)

>
> 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?

While this is wishful thinking, I hope users will use high-order IIR filters sparingly. Most (analog) filter designs I've seen eventually decompose the filter into a set of biquads anyway, so that seems natural. I'm expect the max IIRFilter order to be about 4. But I have no evidence of that. (It would be interesting to create histograms of that for chrome.)

[Daniel Minor]

On Wed, Apr 27, 2016 at 6:35 PM, Karl Tomlinson <moz...@karlt.net> 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

[Karl Tomlinson]

Thanks for the replies, Dan and Roy.

A first order filter node with AudioParam inputs seems a likely
future addition AFAIK.

Even with that though, having a way to apply a custom biquad
without needing to decompose into multiple textbook filters is
useful I think. And I agree that implementing this with
AudioParams seems unnecessary and risky wrt stability.

So I think the IIRFilterNode will still be useful as a basic
building block for authors (and that is the kind of node that Web
Audio should be providing).

The discussion re extending BiquadFilterNode for this has passed
but there is an elegance in the generality of IIRFilterNode.

Daniel Minor writes:

> 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 wanted to think this through now because, once this is shipped,
we can't take it back, so the cost is ongoing.

When Gecko has used Blink or Webkit's implementation in the past,
the WG has sometimes used this to argue that quirks in multiple
existing implementations should be maintained even if not
desirable.

Sometimes we just live with the quirks. Other times the nodes
have been deprecated and replaced, but we still need to continue
to support the old nodes for backward compatibility.