# Calculating Stability of Phaser Feedback Loop

I have been doing some experiments with phaser programs. I really like setting the phaser feedback to really high levels, such that the effect is really metallic and resonant, almost like a physical modeling instrument. The problem with this is that it's easy to go overboard and get runaway feedback which gets harsh extremely quickly.

I am wondering if there is a way to calculate the point at which self oscillation will occur, given the number of phaser poles, the cutoff frequency of the allpass filters, and the feedback level.

The phasor I am using uses a variable number of 1 pole allpass filters in series, each defined by the equation:

$$y[n] = A \cdot ( x[n] + y[n-1] ) - x[n-1]$$

where:

$$A = \frac{1 - \pi \cdot \frac{cutoff}{SampleRate}}{1 + \pi \cdot \frac{cutoff}{SampleRate}}$$

Here is a signal flow diagram:

Ultimately what I am looking for is an equation I can use to calculate the following:

Given a phaser with x poles with y cutoff, self oscillation will being at feedback level z

Can anyone recommend a good method or some resources I could use to figure this out?

## 1 Answer

A feedback loop like this (with enough phase diversity) will be stable if the magnitude of the loop gain is less than unity. In this specific example, it's really simple: make sure your feedback coefficient needs to be less than 1.

So it's $|z|<1$, x and y don't really matter.

• That is simply not the case in practice. I have a feedback (z) coefficient of less than 1, and at low cutoff values for the allpass network (which in turn means high feedforward and feedback coefficients) self oscillation can occur if the network is given an input with high enough amplitude – Emmett P Dec 3 '17 at 0:19
• @EmmettP: Sorry, but this works just fine in practice. I've shipped products with this constraint that a large number of people are using and so far no one has complained about any stability problems. The math bears this is out as well: feedback loops are always stable if the loop gain is below unity (including all tolerances and noise issues, that is). If you have trouble at low frequencies, it's probably due to an implementation or numerical problem. Are you using fixed or floating point ? – Hilmar Dec 4 '17 at 2:43
• I am processing a 16 bit fixed point audio input, but I 32 bit variables for the processing to avoid rollover. I found that by clipping the accumulator at the 14th bit (max value of +/-16383) I could prevent the runaway oscillation from occurring. I suppose this had something to do with numbers getting to large for the accumulator to handle. – Emmett P Dec 4 '17 at 23:37
• Or perhaps it is something to do with inaccuracy in feedback scaling. I am using a fractional feedback scaler that multiplies the feedback by a value range 0-1023 then divides by 1024 (>>10 for efficiency). Do either of these sound like they might be the culprit? – Emmett P Dec 4 '17 at 23:38
• @EmmettP: fixed point processing is quite difficult. and requires a fair bit of analysis and up front modelling. In essence, you need to determine the correct scale factor and shift for every single variable in the code. This scaling also depends on your filter coefficients, so you need to build in some constraints and do a worst cases analysis around this. If any possible, do a 32-bit floating point implementation and than scale. limit and clip only at the very end before you out to the DAC. – Hilmar Dec 6 '17 at 14:27