On Tue, Jul 13, 2010 at 1:19 AM, wrote:
Yes, the meters in envy24control --
-- 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
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
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
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
Linux-audio-dev mailing list