On Mon, Jul 12, 2010 at 4:40 PM, <fons@email-addr-hidden> wrote:
> That comment is still true. A K-meter is for signals
> that are in a sense the 'end result' you listen to.
> For monitoring 'technical' levels in digital audio
> the peak digital level is all you need.
As I mentioned, the main use would be for the "digital mixer" meter --
which is a single meter -- always visible on the left hand side no
matter which tab-panel selected -- representing the output of all the
inputs to the 36 bit wide digital mixer. The inputs feeding the
meter&mixer can include audio from 8 PCM outs + 2 SPDIF outs, as well
as 4 inputs, and 2 SPDIF inputs. Very much the "end result" you listen
to. It is normally used for "zero latency monitoring" of analog inputs
-- in which case the digital mix out is routed to the headphones. You
can also use it as an internal digital mix/route before going to hard
disk or DAW input -- very convenient as such.
However, also for the other individual inputs, one may find the option
of "K-system" metering useful for setting "average recording levels".
Our single instruments can be like "entire bands" and do not afford
proper metering into their own virtual digital mixer -- for example
the one hidden inside my db50xg clone. Or any other instrument capable
of simultaneous playback of 16 midi channels w/o individual mix-outs.
For that situation, or recording any "submix", you still might want to
have an indication of RMS or average values... if it's a meter that
claims to be able to present "perceptual loudness" and its useful,
great! i've found jkmeter useful for just such purposes...
Lets say you're recording a synth-line that is "expressive' -- you
might well want to use K-levels as a baseline reference level 0db for
recording, leaving either 14 or 20db headroom for the resonance on a
filter, or the loudness multiplication that arpeggiation, beat matched
reverberations,can give...
And of course the "K-level" could just be a slider or the ability to
move the meter background around via direct manipulation -- the
audio-equivalent of the little ring you twist around on a compass ....
>A much more serious failure of Envy24ctl's meters is
>that they don't provide any level indication at all.
>Where is -10 dB ? or -20 dB ? Except for checking if
>a signal is present they are just eye candy.
I thought about fixing this along with the peak-level-hold issue, and
decided to not add any new bugs in fixing another :-) That "fix" would
be for another patch....
The hardware metering delivers levels from 0-255. According to
http://alsa.cybermirror.org/manuals/icensemble/envy24.pdf the values
represent:
"Peak data derived from the absolute value of 9 msb. 00h min - FFh max
volume. Reading the
register resets the meter to 00h."
If anybody wants to contribute a mapping of 0-255 in db as the "9
msb's" of a 36bit deep mixer -- I'll add peak levels. And fons, if you
have any suggestions for displaying averaged, rms'd or "k-system'd"
versions of these 0-255 loudness values from the hardware metering,
that would be helpful too -- all I'm really looking for is "average
listening level/perceptual level". But the hardware metering may not
be able to provide that in a meaninful fashion.
Speaking of making my brain hurt -- I really would not have done the
meters as done in envy24control. I really hate the concept of
emulating the look of real gear down to the level that you have to
"quantize" to individual LED's... real helpful when you're checking to
see if you're an "led" away from clipping, or right there.... and all
the heinous computation to draw individual rectangles via a bunch of
offscreen gdk_draw_pixmap()-per-LED and then a big BLIT (w/o damage
area computation, it just blits the whole meter each update) -- each
and every time there's a meter value change, for each visible
meter.... All quite silly when it's quantized to 255 levels in the
first place.
And my patch adds to the mess and inefficiency by adding a single
gdk_draw_line() representing the peak level, which comes after the
original code redraws all the led-segments of each meter, for each
value refresh... Using the same damn for-loop, instead of computing
its pixel offset directly -- IMHO the entire meter needs a rewrite!...
which is why i was looking at jkmeter...
For this time, I was looking towards a clean patch to the existing
code, not a rewrite: http://nielsmayer.com/npm/602903.patch
be sure to checkout gint level_meters_timeout_callback(gpointer data) in
http://git.alsa-project.org/?p=alsa-tools.git;a=blob_plain;f=envy24control/levelmeters.c;hb=HEAD
-- Niels
http://nielsmayer.com
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Tue Jul 13 08:15:01 2010
This archive was generated by hypermail 2.1.8 : Tue Jul 13 2010 - 08:15:02 EEST