[sdiy] Digital VU

Tom Wiltshire tom at electricdruid.net
Fri Aug 4 02:49:32 CEST 2017

I totally agree, Brian. Bit-shifting only makes sense on processors that have fallen on hard times and/or lost their fortunes. There are lots of those about, but I don’t know if that’s what Tim has in mind.

But if we’ve got a floating point processor to throw at a VU meter, why are we even talking about it? Do it the hard way, do the sums, do the filtering, whatever it takes. He’ll have bags of time left over. No problem.

I also agree about the bit positions - obviously you can’t just map the the bits to the LEDs. It’d be nice, but that’s *too* simple. Like you say, an instruction that finds the most significant bit helps a lot, and many processors or DSPs have such a thing. C often offers some way to get to underlying assembly instructions, and in cases like this, that could save a lot of time. Smaller steps don’t come so easily, but I’m sure there’s a way. 28 LEDs in 2dB steps is only a 56dB range, so we’re probably not doing a totally linear range at that, but it’d only be a 9 or 10 bit lookup table, so that would be realistic.  28 LEDs in 3dB steps is 84dB which covers the full range better, and that’s a 14-bit range, more or less. You could do that by looking at the highest bits and lower bits to get the 3dB steps. For example, if 64 is 20dB, then 128 is 26dB (bit shifted up one place), and 96 is 23dB (bit shifted up “half a place”).

Analog processing is another possible solution, but the original brief ruled it out pretty thoroughly, so I didn’t consider it: "I'm looking at doing a VU meter in digital land. Sample the audio and do all the work in code.”
I based my answer on that and assumed the minimum hardware to get the job done. More is always nice…;)


       Electric Druid
Synth & Stompbox DIY

> On 3 Aug 2017, at 23:41, rsdio at audiobanshee.com wrote:
> 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.
> Brian
> 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?
> _______________________________________________
> 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