Recovering from unstable biquad filters?

[rtoy]

Describe the issue
In , there is a report where a test modulates the detune parameter so fast that it appears as if the biquad filter becomes unstable (or at least unbounded for the given input). What is happening is that the filter quickly goes to +/- infinity, which quickly becomes NaN. This propagates forever because the filter internal state is now just NaN.

If the filter parameters and connections are changed so that the filter is now stable, the output is still NaN because the internal state is NaN, no input can ever change that.

Do we need to do anything about this? It's easy to say that the state should be reset to zero in this case, but that seems weird too.

I'm leaning towards Garbage In-Garbage out. Don't do that.

[rtoy]

Teleconf: Garbage in-garbage out. Add a note to the spec that unstable filters can be created and we won't do anything about it. Similar to how IIRFilterNodes allow you to create unstable filters.

[rsimmons]

I'm in favor of reseting the internal state if it becomes NaN. The problem with "garbage in garbage out" is that we can't precisely define what "garbage" is. This reliably occurs with certain AR modulation.. but how do we know it won't also occur with modulation from fast envelopes? This could come up in a web-based synth if the end-user sent a fast LFO to the filter cutoff. It would be extremely annoying for devs to have to add code to detect and correct for this (recreating nodes, etc.), so it seems better to fix the implementation.

[rtoy]

I sympathize with your position, I just don't really know what to do. By "garbage-in/garbage out", I meant that the spec shouldn't try to determine the user's intent. If you specify something, then it happens. You want unstable IIRFilters? You can have them. Unstable biquads? Go for it; we won't stop you.

Resetting the state when NaN occurs just changes the problem from the graph going silent to the graph producing momentary silence (until the state is reset), then starting over with a new effect until it blows up again. In either case, it will be hard to determine what went wrong.

The main advantage of resetting the state is that the biquad could recover if you somehow magically changed the automations or audio input so as not to make it unstable. But you wouldn't know why it suddenly sounds good again. But maybe that's a good enough reason to reset. (But then what about IIRs? We should be consistent here.)

[hoch]

Conclusion from Teleconf: We're going to add an informative note saying UA may warn users when a filter becomes unstable and starts producing NaN.

[rtoy]

Just to add a little more detail on the conclusion. Basically no matter what action is taken the result will be hard for the developer to understand. Going silent due to NaN is hard to understand. Producing silence and then resetting the state to produce output is equally hard to understand. So the best course seems to be just producing a warning message to let the developer know that NaN has occurred in the state of the filter.

[adenflorian]

Is their a guaranteed way to prevent a biquad filter from becoming unstable, besides not automating the parameters?

If no, then that means our only option is to recover from an unstable filter, which first requires us to be able to detect when a filter is unstable, and then I believe we have to replace the filter with a new one?

I'm not trying to change the decision, just looking for guidance on what we're supposed to do.

It is the developers responsibility to manage this.

I guess I'm asking, how do we manage this?

[rtoy]

I think k-rate automation is ok. But maybe that's because no one has come up with an automation and corresponding input that causes unbounded output.

Yes, currently it's basically up to you to detect that the output of the filter is infinity or NaN and then replace the filter. However, I wouldn't be opposed to adding, say, a resetState() method to reset the internal filter state. Might be useful too for other nodes with internal state.

[adenflorian]

resetState() sounds nice, and maybe also a filterunstable event that we can add a listener to?
Like filter.addEventListener('filterunstable', () => filter.resetState())

[rtoy]

Determining if the filter is unstable is tricky. Chrome prints a console warning if the state has NaN in it, but that doesn't mean the filter is unstable. You can get that warning by feeding in NaN to a fixed biquad. Or maybe even by feeding a (very large) amplitude signal into the filter.

[yishengjiang99]

I reproduced this with much less dramatic repo steps..

[rtoy]

Do you have a repro case you could share with us? Are you proposing the spec should be changed in some way?

[yishengjiang99]

No I like the fact that this api lets you break things like this. Less guard rail. I was bragging, not complaining..

…

Sent from my iPhone

On Apr 22, 2020, at 7:05 AM, rtoy ***@***.***> wrote:  Do you have a repro case you could share with us? Are you proposing the spec should be changed in some way? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.