[sdiy] VU meter algorithms

Tom Wiltshire tom at electricdruid.net
Mon Mar 18 20:24:17 CET 2019


Very interesting, Ben, and a bit different from what I’ve been doing. Where did you learn that? Is that a invention of yours or a standard algorithm?

Thanks,
Tom

==================
       Electric Druid
Synth & Stompbox DIY
==================

> On 18 Mar 2019, at 19:11, Ben Bradley <ben.pi.bradley at gmail.com> wrote:
> 
> Practically speaking, it's rare if ever that a musical signal has a
> 20kHz frequency as its biggest signal. 40kHz sampling of the direct
> audio should be plenty.
> 
> Having hardware to do the rectification and filtering would certainly
> work (look up "precision rectifier" circuits where one or more diodes
> are in an op-amp's feedback loop), but again, I don't see them as
> necessary. Digitizing audio at sufficient sample rate and resolution
> is pretty cheap thesedays. The problem is then back to the OP's
> question, finding good algorithms for level indication.
> 
> For peak, use a "hold time" of perhaps 1/2 or 1/5 second. When a peak
> is detected, set the bargraph level to it, and set a timeout of the
> hold time. When the timeout occurs, set the peak level to zero. If
> there's still a signal, it will immediately set the currently held
> peak to the new peak value. But wait, there's more: Have the peak
> detection code continue to run during this timeout time, If there's a
> new higher peak, save it as the current peak AND reset the timeout to
> the hold time, so it stays at this new level.
> 
> For the "instantaneous level" value, get the AVERAGE over a shorter
> time, maybe 1/10th to 1/20th of a second. Rectify the samples, add
> them up over the period of time, and you get a number proportional to
> the average level that you can scale as appropriate, such as dividing
> by the number of samples in the time period.
> 
> 
> On Mon, Mar 18, 2019 at 1:47 PM 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 18 Mar 2019, at 15:38, rburnett at richieburnett.co.uk wrote:
>>>> 
>>>> Ahhh, but how high a sample rate do you need to use to be sure
>>> that you take a sample at the peak of a waveform!?!?!? ;-) > >
>>> -Richie, > > > > 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 >>
>>> _______________________________________________ >> Synth-diy
>>> mailing list >> Synth-diy at synth-diy.org >>
>>> http://synth-diy.org/mailman/listinfo/synth-diy
>>> 
>>> 
>>> _______________________________________________
>>> Synth-diy mailing list
>>> Synth-diy at synth-diy.org
>>> http://synth-diy.org/mailman/listinfo/synth-diy
>>> ?
>> 
>> -- ScottG
>> ________________________________________________________________________
>> -- Scott Gravenhorst
>> -- http://scott.joviansynth.com/
>> -- When the going gets tough, the tough use the command line.
>> -- Matt 21:22
>> 
>> _______________________________________________
>> Synth-diy mailing list
>> Synth-diy at synth-diy.org
>> http://synth-diy.org/mailman/listinfo/synth-diy
> 
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at synth-diy.org
> http://synth-diy.org/mailman/listinfo/synth-diy




More information about the Synth-diy mailing list