27 Jul
2013
27 Jul
'13
2:20 p.m.
Hi Fons,
Would you mind explaining how the vumeterdsp.cc from jmeters works?
In particular how you arrive at the filter-constant:
_w = 11.1f / fsamp;
With the DSP using a 2nd order low-pass filter, and since VU should have
an integration-time of 300ms, I'd have though it should rather be:
_w = (1.0 - exp(-2.0 * M_PI / 0.3 / fsamp)) / 2.0;
for large values this can be approximated by _w = 10.468 / fsamp;
What am I missing?
-=-=-=-
I suppose the gain is arbitrary, seeing as it is mapped to a GUI element
without any numeric display, anyway. But is there something special about:
_g = 1.5f * 1.571f;
1.5 * M_PI/2 ?? ie 90 degree deflection? But why the 1.5?
-=-=-=-
The context of all this is re-using your code to implement a VU meter in
Ardour3. For reference, the source-code is at
https://github.com/Ardour/ardour/blob/master/libs/ardour/vumeterdsp.cc
Some experienced beta-testers contested the ballistics of the meter and
I'm trying to get to the bottom of it...
Since this might be of general interest, I'm CCing LAD.
thanks in advance,
robin
27 Jul
27 Jul
4:19 p.m.
On Sat, Jul 27, 2013 at 02:19:56PM +0200, Robin Gareus wrote:
for large values this can be approximated by _w =
10.468 / fsamp;
What am I missing?
The correct interpretation of 'integration time'. A VU must have
between 1 and 1.5 % overshoot, it is not critically damped.
See the red curve in the slides for the ebumeter presentation
at LAC 2011. The actual value used is found by measuring the
result, which is the only correct way.
I suppose the gain is arbitrary,
Please don't insult me :-)
It is not arbitrary, output will be 1 for a full scale sine wave.
The *dsp classes are meant to be usable on their own and don't
depend on anything specific to jmeters. You can just copy them
into Ardour or whatever.
The only thing that links them to the GUI is the _m member, which
keeps the maximum output value since the GUI (or whatever) last
read it. This improves accuracy if the GUI update frequency is
on the low side, e.g. you may not be able to see the overshoot
otherwise. The same is done with the PPMs where it is even more
important.
1.5 * M_PI/2 ?? ie 90 degree deflection? But why the
1.5?
The 1.5 compensates for the DC gain of the filter. It's basically
two first lowpass stages in series, but there is some feedback to
get the less than critical damping, and this changes the gain.
The second filter is undersampled by a factor of 4, it gets a
lowpassed input anyway.
A VU measures the average of the absolute value of the signal.
For a unity amplitude sine wave this is 2 / pi, hence the second
factor.
Why such a dinosaur meter in Ardour ? You'd be better off with
a DIN PPM or a K-meter, and they don't take any more CPU.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
6:32 p.m.
On 07/27/2013 04:19 PM, Fons Adriaensen wrote:
The actual value used is found by measuring the
result, which is the only correct way.
OK. there's that :)
How did you measure it? Did you plot the output of the filter for
various input signals? or fit the coefficient to some data?
[..]
Many thanks for the detailed explanation!
FWIW, I took a somewhat empirical approach: feed 4 VU meters with the
same input, video-tape it and step the video frame-by-frame:
1) hardware from a PreSonus TubePre
2) http://www.lsraudio.com/lvlmeter.html
3) http://www.pspaudioware.com/plugins/tools_and_meters/psp_2meters/
4) Ardour 3.3-63 (jmeters-0.4.1 code)
(I first sure jmeters and ardour3's use of the code show identical data
on a linux-box. ..but I did not bother to compile jmeters on OSX where
the tests run using AU effects for (2), (3) )
All meters are set to -18dBFS = 0dBu, 0dBu == 0VU
(1) Has an incorrect deflection to start with. -18dbFS 1KHz sine wave
calibrated to 0VU; then changing the volume by +-3dB deflects the meter
by about -7dB, +4dB, besides it overshoots like hell.
one down.
(2) rises way to fast and falls off too slow. It also overshoots maybe
10%. On the upside it has a neat reflection of my non-existent
living-room windows in the meter-glass which easily makes up for that :)
see http://robin.linuxaudio.org/tmp/vu-011.webm
..another one out.
(3) looks generally promising - but a simple sine-sweep 30second
20Hz-20kHz at -18dBFS shows some issue: Around 5kHz, The PSP2 meter is
off by -2VU. see http://robin.linuxaudio.org/tmp/vu-010.webm
The VU-meter specs say "[for a sine wave] the [meter] reading should not
depart from the reading at 1kHz by more than 0.2 dB from 35 Hz to 10 kHz
[..]"
which leaves us with... Congrats Fons.
Here's a series of various sine-waves and a kick-drum sample going into
(3) and (4). Interestingly jmeters' algorithm is always a tad below the
PSP meter. But that is somewhat consistent with the
band-pass-filter-like artefact that the PSP meter shows at ~5kHz. ie.
the PSP meter emphasizes lower frequencies:
http://robin.linuxaudio.org/tmp/vu-008.webm
..and some Beethoven, just for the fun of it :)
http://robin.linuxaudio.org/tmp/vu-001.webm
Why such a dinosaur meter in Ardour ? You'd be
better off with
a DIN PPM or a K-meter
Those already in there and working just fine.
Cheers!
robin
7:32 p.m.
On Sat, Jul 27, 2013 at 06:32:33PM +0200, Robin Gareus wrote:
How did you measure it? Did you plot the output of the
filter for
various input signals?
Yes. The VU was the easiest one. First get the overshoot right,
that's easy. Then plot the output of the DSP code, note the time
when it reaches 99%, adjust filter coefficient.
For the IEC I and II meters it's a lot more difficult. They are
specified by a drop rate (easy), and their response to various
burst test signals. For the real ones, the result is the combined
effect of a non-linear pseudo-peak detector, a non-linear mapping
to the meter scale, and the ballistics of the actual mechanical
meter (not always driven from a constant impedance, hence variable).
That is not something that will correspond to some readable equations.
The only way to get those right is to create some mathematical model
that you believe could do the right thing, then tune its parameters
by trial and error. If that fails try another model, until you get
well within the allowed error margins.
The most difficult one was the CCIR-468 response implemented in
jnoisemeter - that is a really weird one - the combination of
two interacting pseudo-peak detectors. There is an (unofficial)
equation for it which is rather useless and fills an A4 page.
which leaves us with... Congrats Fons.
TNX ! But I'm not really surprised - I wrote the jmeters code
because I found *nothing* that really worked as it should have.
And as your tests have shown again, most don't even come close.
The videos are fun to watch...
BTW, while I have no problem with 'real' VUs, a bargraph
display - even if correct - looks somewhat hyperkinetic
to my taste... I wouldn't stand looking at it for too long.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
4165
days inactive
4165
days old
linux-audio-dev@lists.linuxaudio.org
3 comments
2 participants
participants (2)
-
Fons Adriaensen -
Robin Gareus