Re: [alsa-devel] [LAD] FIxed alsa-tools' envy24control missing peak level meters and "Reset Peaks"
On Tue, Jul 13, 2010 at 1:19 AM, fons@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/l... -- 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
On Tue, Jul 13, 2010 at 09:54:58PM -0700, Niels Mayer wrote:
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).
It should at least use the XDrawRectangles(), which draws a list of them in a single call.
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.
Depends. A linear mapping is not really the best you can do.
Ciao,
On Tue, Jul 13, 2010 at 9:54 PM, Niels Mayer nielsmayer@gmail.com wrote:
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).
Patch for https://bugzilla.redhat.com/show_bug.cgi?id=602903 (see also http://old.nabble.com/FIxed-alsa-tools%27-envy24control-missing-peak-level-m... )
(1) http://nielsmayer.com/npm/Screenshot-Efficient-Meters-Envy24Control.png * To see what the new meters look like. (2) http://nielsmayer.com/npm/Efficient-Meters-Envy24Control.tgz * Contains levelmeters.c and x86_64 binary 'envy24control' that should at least work on Fedora 12 and OpenSuse and other 2.6.32-based distros. (3) http://nielsmayer.com/npm/Efficient-Meters-Envy24Control.patch * To apply the patch, grab the most recent stable release ( ftp://ftp.alsa-project.org/pub/tools/alsa-tools-1.0.23.tar.bz2 ) or git pull from trunk of the "alsa-tools" project. * After unpacking and assuming you've got the patch in ~/Efficient-Meters-Envy24Control.patch.patch do:
cd alsa-tools-1.0.23 cat ~/Efficient-Meters-Envy24Control.patch | patch -p1
* It should give message "patching file envy24control/levelmeters.c" * Follow the directions to compile alsa-tools.
FYI here's what my "top" processes look like when running a test to output individual streams to all 10 PCM output channels -- note X consumes between "1.7%" to "2.0 %" and "envy24control" "0.7%" to "1.0%":
15210 npm 20 0 643m 14m 8964 S 6.6 0.4 0:05.85 gst123 15184 npm 20 0 643m 14m 8984 S 6.3 0.4 0:13.11 gst123 15190 npm 20 0 643m 14m 8980 S 6.0 0.4 0:12.48 gst123 15172 npm 20 0 643m 14m 8968 S 5.6 0.4 0:15.42 gst123 15178 npm 20 0 643m 14m 8984 S 5.6 0.4 0:14.17 gst123 13684 root 20 0 527m 112m 31m S 2.0 2.8 3:26.11 X 13923 npm 20 0 863m 60m 37m S 1.0 1.5 2:49.08 plasma-desktop 14163 npm 20 0 597m 27m 15m S 1.0 0.7 1:08.29 chrome 14155 npm 20 0 1038m 170m 14m S 0.7 4.3 1:00.87 chrome 15226 npm 20 0 192m 9316 6908 S 0.7 0.2 0:00.51 envy24control
Here's the envy24control from my first patch, using the original meters that cause many separate XDrawRectangles for each LED-looking segment. The performance difference is quite noticeable as the fans start running louder and the system load climbs upwards as soon as the original envy24control starts running: X consumes 5.7-10% CPU, and envy24control between 2.0% and 2.7%.
15172 npm 20 0 643m 14m 8968 S 6.1 0.4 0:53.83 gst123 15178 npm 20 0 643m 14m 8984 S 6.1 0.4 0:51.48 gst123 15190 npm 20 0 643m 14m 8980 S 6.1 0.4 0:49.60 gst123 15210 npm 20 0 643m 14m 8964 S 6.1 0.4 0:44.01 gst123 13684 root 20 0 527m 112m 31m S 5.7 2.8 3:42.78 X 15184 npm 20 0 643m 14m 8984 S 5.7 0.4 0:51.07 gst123 15398 npm 20 0 192m 9332 6908 S 2.4 0.2 0:02.32 envy24control.f 14163 npm 20 0 597m 27m 15m S 1.0 0.7 1:15.54 chrome 13923 npm 20 0 863m 60m 37m S 0.6 1.5 2:55.04 plasma-desktop
Just to show that it's the same performance as the original envy24control from alsa-tools-1.0.22-1.1.fc12.ccrma.x86_64:
15178 npm 20 0 643m 14m 8984 S 6.3 0.4 1:28.72 gst123 15190 npm 20 0 643m 14m 8980 S 6.3 0.4 1:26.65 gst123 15210 npm 20 0 643m 14m 8964 S 6.3 0.4 1:20.59 gst123 15184 npm 20 0 643m 14m 8984 S 6.0 0.4 1:28.21 gst123 13684 root 20 0 527m 112m 31m R 5.6 2.8 4:21.30 X 15172 npm 20 0 643m 14m 8968 S 5.6 0.4 1:31.51 gst123 15455 npm 20 0 192m 8700 6316 S 2.3 0.2 0:01.74 envy24control 14163 npm 20 0 597m 27m 15m S 1.3 0.7 1:23.02 chrome 13923 npm 20 0 863m 60m 37m S 0.7 1.5 3:00.72 plasma-desktop
-- Niels http://nielsmayer.com
participants (2)
-
fons＠kokkinizita.net -
Niels Mayer