Skip to main content

Topic: Design caveat for compressors, limiters, expanders... (Read 269 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • jsdyson
  • [*][*]
Design caveat for compressors, limiters, expanders...
Recently found a bug in a piece of a gain control project that I have been working on.   It shouldn't really be a major issue for most people, and only happens when trying to do something special in a dynamic range control project.  This bug can even happen if you already know that this concept can cause troubles -- but will invariably happen over and over again if more than one layer of gain control filtering is needed.   This fact can make the gain control circuit ( or algorithm) need to be more complicated or tricky than otherwise one might think.  SIMPLE straight single attack/decay TC doesn't cause this kind of problem -- but there one must be
careful about aliasing and/or intermod (depending on the realm of where the algorithm runs.)

The effect of this bug is that the gain control will sometimes sound ragged.  There are workarounds for this problem, while still gaining most of the positive effects...  But whenever you see this kind of circuit, or have the equivalent in software -- beware -- you'll have a harder/harsher sound than what you would expect.   Please refer to the attached PDF, but otherwise if you don't like attachments -- basically it is like this:
raw-level-signal ----- moderate attack/slow decay -- additional fast/moderate RC TC --- further on to gain control element.

I am in the midst of fixing a bug right to mitigate this mistake -- but I already knew about this matter.   Hope this might help any future people working on gain control and not aware of this oddity.

John

  • jsdyson
  • [*][*]
Re: Design caveat for compressors, limiters, expanders...
Reply #1
My previous post was a little garbled -- I tend not to sleep much and often fall asleep while typing (when I do sleep.)  Anyway -- the trouble that I was writing about is related to attempts to avoid ugly mixing of hard/sharp gain changes with audio signals.  So -- what might happen (even though the most trivial scenario in the schematic is possible also) is that one might have a simple attack/decay with separate time constants -- then some kind of nonlinear operation on that gain control signal.   One common kind of such operation might be something like "prefiltered_gain = (threshold / max(threshold, LEVEL))", where LEVEL is the attack/decay filtered gain control signal, and the the threshold is the point where gain control starts.   When the LEVEL increases beyond 'threshold', then the gain starts decreasing from 1.  Depending on the rest of the math, this might be a part of a signal level limiter.  There is an increase in higher level derivatives at the threshold level, and might be a little more nonlinearity added (e.g. the power function so as to produce a controlled compression ratio).

The trouble can occur when adding an RC filter (or another attack/decay filter for certain behavior) later on in the signal chain.  This additional set of time constants can cause a rough edge to the sound when the 'audio processor' is actively following the level.  I haven't carefully reviewed the math and the effect on hearing, but I do know that this behavior can happen.

Unfortunately, the easy answer is to avoid any low pass time constants later in the control chain -- so some imagination/creativity needs to be used to find out how to slow down the transients in the gain control (avoiding strong intermod products and/or aliasing).  This slow down becomes relatively safe again around the 10msec range agani.  I am mostly talking about extra RC delays in the msec range when the gain control slew is also in the msec range.

My own approach to dealing with this problem is based upon the general concept -- don't make the signals (or variables in software) faster than they need to be, and if filtering needs to be done -- try to do it earlier in the chain.

So, normally I maintain two or three copies of the signal level -- one is shaped for ear friendliness, one is shaped to minimally slow down the gain control so that future RC lowpass is not needed, and finally an unfiltered version of the gain signal.   When I am done with the software, I then remove the code/signal that isn't needed.  (Sometimes, I do experimental/conceptual software, and so I make sure that I have pretty good flexibility, but also can clean up the code afterwards.)  * When mixing gain control or signals with other gain control signals that might have been delayed by a filter of some kind, it is important to make sure that the delays do not cause other troubles (e.g. the gain control signal is delayed relative to the signal itself -- might allow the signal to surge in level.)

John Dyson