[sdiy] VU meter algorithms
rsdio at audiobanshee.com
rsdio at audiobanshee.com
Wed Mar 20 07:33:41 CET 2019
If a given design isn’t already processing the audio in the digital domain, then it’s certainly possible to get by with a cheap and simple analog circuit and 500 Hz sampling or less, maybe even as low as 250 Hz. Depending upon the application, that could really save a lot. Thanks for the detailed article, Alwyn.
I got the impression that Tom already needs to sample the audio anyway. If that’s the case, then calculating a meter value should be inexpensive compared to the rest of the audio processing.
Tom, I think your disappointing results are due to applying a traditional decay to the Peak Hold. What you really want is a literal hold of the same value for some amount of time. The value isn’t actually supposed to decay during that time. Also, you don’t want to make the time window as short as 16 samples, otherwise you’ll see the jumpy results that you don’t like.
As Ben described, you want an instant attack that updates the Peak on every sample. Then, rather than using typical signal processing for “decay,” just implement a counter that will hold the value constant for a minimum time (unless a new peak arrives).
To answer your question, what Ben described is the standard algorithm. There are some bugs with the algorithm, and every Peak Hold meter I’ve ever seen has the same bug.
To be specific, the bug I’m talking about is due to the Peak clearing itself after the Hold time. Each new Peak erases the previous Peak. What can happen is that a new “near” Peak can occur right before the Hold time expires, but the algorithm will completely miss this, clearing the Peak almost immediately. The reason I can be sure that Ben’s description is standard is that all Peak Hold meters have this same flaw.
On Mar 18, 2019, at 10:46 AM, Scott Gravenhorst <music.maker at gte.net> wrote:
> Reading this, (and in my naivete) I wonder if part of this could be mitigated by doing
> some analog processing before the digital sampling. Something like a full wave
> rectifier of the signal with a low pass filter that has a leak resistor? Then I think
> the sample rate could be much lower than 40 kHz? As I said - naivete...
> Tom Wiltshire <tom at electricdruid.net> wrote:
>> Well, quite.
>> The short answer is “far higher than any reasonable LED update rate”.
>> If we assume 20KHz as the highest input frequency, then obviously
>> my 40KHz sample rate is inadequate because we might sample at the
>> zero crossings each time. Updating the LEDs at 100Hz would be
>> more than enough (flicker at that speed is already perceived as
>> “variable brightness”) but such a rate is hopeless as a
>> sample rate.
>> But it’s worth pointing out that we’re trying to imitate
>> something that was originally done with moving coil meters and
>> which had quite considerable lag (300msecs attack and decay from
>> what I can find out). So how hard can it be?!
>>> > > > > On 2019-03-18 15:25, Tom Wiltshire wrote:
>>> >> Hi all,
>>> >> Does anyone know of any good resources on bargraph VU meter
>>> >> algorithms, and specifically implementing a “Peak hold” feature?
>>> >> I’m trying to write one - well, I *have* written one - but I’m not
>>> >> overly impressed with its performance. The “VU meter” portion of the
>>> >> code is pretty good: I sample the audio at 40KHz, then rectify it,
>>> >> take the highest sample in a block of 16, and then apply an IIR
>>> >> smoothing filter with a time constant of about 200msecs. That part
>>> >> seems pretty good, although it “under reads” significantly.
>>> >> I’m having worse problems with the Peak Hold dot. This has an attack
>>> >> of zero (so it never misses a peak) but uses a longer decay time of
>>> >> 400msecs or so. But a typical input signal tends to make it jump
>>> >> about, so instead of clearly lighting a single LED, it instead lights
>>> >> two or three intermittently. This makes the display rather confusing
>>> >> to look at.
>>> >> I’d thought to just get stuck in and see how it went (and it went ok)
>>> >> but I think now might be a good time for a bit of research. This is a
>>> >> solved problem, so someone must have dealt with these issues before
>>> >> me.
>>> >> Thanks,
>>> >> Tom
More information about the Synth-diy