[alsa-devel] [LAD] FIxed alsa-tools' envy24control missing peak level meters and "Reset Peaks"

[Niels Mayer]

On Tue, Jul 13, 2010 at 1:19 AM,  <fons at kokkinizita.net> wrote:
>On Mon, Jul 12, 2010 at 06:18:29PM -0700, Niels Mayer wrote:
>> 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...
>
> That is indeed quite absurd.

Yes, the meters in envy24control --
http://git.alsa-project.org/?p=alsa-tools.git;a=blob_plain;f=envy24control/levelmeters.c;hb=HEAD
-- are absurd! What's even more absurd, is to have the benefits of the
ice1712's hardware metering squandered by drawing thousands of
rectangles per second (each individual "LED" on each meter is a
separate x draw-rectangle call). The existing envy24control meters are
an abomination of inefficiency! Especially when used with a remote X
display.

As a second patch (coming soon), I've rewritten  the meters in a more
sensible fashion, drawing a single rectangle to represent the
instantaneous level (2-3 X-primitive draws per meter total and one
blit, versus hundreds of draws and a blit per value change per meter
in the original code). I'm also being a little more careful about not
needing to redraw the entire meter for each change -- using the
monotonicity of the audio signal being represented to optimize the way
you draw it; not redrawing if nothing has changed, etc.

And since the hardware metering already quantizes to 256 levels --
there's no point in re-quantizing those to individual "virtual LEDs"
as is done w/ the current envy24control.

The result so far are promising: Here's 'top' output (*) using the new
envy24control. Note the load is lower, and 'envy24control' and 'X'
both use much less CPU. In fact running this meter lowers the system
load. whereas running the old envy24control raises it (and makes the
fans run faster!).

 top - 21:30:13 up 11:30,  9 users,  load average: 0.02, 0.11, 0.06
 2664 root      20   0  544m 134m  34m S  2.6  3.4  26:03.51 X
 9404 npm       20   0  192m 9340 6908 S  0.7  0.2   0:01.72
envy24control

The new metering gives 2.6% CPU for X, and 0.7% CPU for the
new-metered envy24control; Versus 6.3% CPU for X and 2.7% for the old
metering in envy24control (the one from my first patch):

 top - 21:25:57 up 11:25,  9 users,  load average: 0.10, 0.09, 0.03
 2664 root      20   0  544m 134m  34m S  6.3  3.4  25:50.67 X
 9398 npm       20   0  192m 9368 6940 S  2.7  0.2   0:16.81 envy24control

Now granted this is not a scientific test, and "top" is not exactly
the best way to gauge performance. But it does suggest that the
computational complexity caused by the bad metering algorithm directly
translates to higher-power consumption, higher loads, and poorer
performance.

Compared to the existing envy24control metering -- It would probably
me more efficient to actually compute RMS levels off the audio stream
-- or even hook up jkmeter through jack -- instead of using the
hardware metering data through these computationally wasteful level
meters.

-- Niels
http://nielsmayer.com