[sdiy] Digital VU

rsdio at audiobanshee.com rsdio at audiobanshee.com
Fri Aug 4 00:41:48 CEST 2017

Hey, Tom, bit-shifting only represents a savings on processors that have no floating point support, or which require more cycles for floating point calculations than integer. Tim hasn't specified which processor will be used, so it's entirely possible that an elaborate scheme won't be any faster. Keep in mind that floating point operations do tons of automatic shifting and drop bits (or bytes) at the least significant end of the word, and all of this can be done in a single cycle.

Granted, there are fixed-point processors, including DSP, where your manual technique would be a win.

As for deriving LED values directly from bit positions, I see a couple of problems. First, it would be impossible to use all 28 LEDs in Tim's display if they were assigned 6 dB steps. His plan to use only 2 or 3 dB per step is best. Second, the bit assignment can't be direct or you'll get random bit patterns instead of the usual bar graph that people expect in a meter. The algorithm to find the most significant bit and then set the rest of the bits to obtain a bar graph is not exactly trivial, although a few processors have built-in instructions that could do this from assembly. Standard C doesn't usually provide direct access to these kinds of complex instructions.

Note that if floating point is used in the filter, then the exponent of the final result could be used to provide 6 dB steps directly, although I've already pointed out that those steps are too large for Tim's 28-LED display.

Getting back to Tim's original question, I'd recommend handling some or almost all of the processing in the analog domain since the circuity would be rather simple. First of all, you could use a simple comparator to feed the typical VU Peak (clipping) indicator, driving an LED and a GPIO on the processor. In addition, full-wave rectification can be done with diodes and op-amps ahead of the A/D input. This allows you to feed a bipolar audio signal into a positive-only A/D without DC-biasing, which could really simplify things in a Euro setup. Finally, some simple RC filtering would help both with Nyquist requirements and to satisfy the VU smoothing requirements. The resulting analog signal could be sampled at a much lower rate, leaving only minimal calculations for a bar graph with moving peak.


On Aug 3, 2017, at 2:47 PM, Tom Wiltshire <tom at electricdruid.net> wrote:
> If it were me, I’d be looking for a reasonable filter coefficient that I could implement as a bit shift to save a lot of mucking about with “hard sums”. It’s a lot easier to shift a 32-bit number 15 places right than to multiply it by 0.000030517578. Shift it up one place, then throw the bottom two bytes away. Bingo! Donner kebab math! Dirty, but good! Like that, you can keep the higher sample rate, since you’re not doing anything complicated,.
> I’d probably also decide that “divide by two” and “-6dB” are close enough that I don’t care and use that to derive LED values directly from bit positions in the result - Richie’s “exponentially-spaced illumination thresholds” . You may not feel the same way, and could tweak it accordingly.
> On 3 Aug 2017, at 19:44, Richie Burnett <rburnett at richieburnett.co.uk> wrote:
>> You can use simple 1st order IIR digital filters for the attack and decay "ballistics". Sure the cutoff frequency is very low compared to the sample rate, but you just need to make sure you keep track of the current filter state to a sufficient number of bits of resolution.
>> I would be wary of decimating. You might actually need to do some interpolation if you are to avoid missing peaks that occur at instants that are between samples. Search about "inter-sample overs".
>> You'll probably also want to do some sort of log approximation too, to make the display scale linear in dB. Or use exponentially spaced illumination thresholds for your LEDs.
>> -Richie,
>> ---- Tim Ressel wrote ----
>>> I'm looking at doing a VU meter in digital land. Sample the audio and do 
>>> all the work in code. I am wondering what is the best way to approach 
>>> the filtering. There needs to be a lowpass filter thingie with a very 
>>> low cutoff, which makes the ratio of cutoff to sample rate very small. 
>>> The obvious solution is to decimate the signal and get the sample rate 
>>> down to a reasonable number. My concern here is the lp filter is low 
>>> order and tails way out in frequency. Is decimation going to affect its 
>>> ability to display transients? Another approach is to have a huge FIR 
>>> filter, but we are talking lots of calculations per sample.\
>>> Any thoughts?

More information about the Synth-diy mailing list