Bug 602903

Created attachment 431282 [details]
Patch fixing missing implementation of holding peak levels and clearing with "Reset Peaks"

I got tired of this feature being absent in envy24control. Checking the sources, both of the latest alsa-tools-1.0.23/envy24control and also from the 'git' trunk, I noticed that this functionality was compltely missing. Specifically, the "Reset Peaks" button callback did nothing, and there was no code to gather peak levels from the metering.

So I implemented the missing feature. 

Please include with Fedora and Send upstream ASAP!

FYI, 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 ~/602903.patch do:
>> cd alsa-tools-1.0.23
>> cat ~/602903.patch | patch -p1

it should give message "patching file envy24control/levelmeters.c"

At that point follow the directions to compile alsa-tools.

Created attachment 432313 [details]
rewrite envy24contro metering l for better efficiency and less useless, obfuscating eye-candy

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 (up to 12 simultaneously on "PCM Outputs" panel.  The "LED"s arequite silly when the hardware metering returns 0-255 values in the first place.

As a second patch 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).

(see also 
http://old.nabble.com/FIxed-alsa-tools'-envy24control-missing-peak-level-meters-and-"Reset-Peaks"-ts29144830.html
)

(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, this all looks really cool - thanks for your work, but it would be much better discussed upstream at ALSA. Even though I have an Envy24 myself, we don't normally apply patches like this in downstream distributions, and I'm sure the ALSA project would much appreciate your efforts and contribution. Not to mention that they would benefit all other distributions too.

(This applies doubly so for the debate about quantisation of meters; it really wouldn't be right to be making changes like that here in Fedora.)

Created attachment 434261 [details]
Final updates to envy24control

I'll be posting/submitting these updates to ALSA and posting to linux-audio-dev and alsa-dev mailing lists. Just adding these here to obsolete my old patches and give those interested access to the new:

   (July 2010) (0) After a decade, incremented version to 1.0. (1)
   Implemented "Peak Hold" functionality in meters and reimplemented meters
   for increased efficiency and lower X resource usage. (2) All volumes are
   represented as decibels, including the 0 to -48dB range of the hardware
   peak-meters, the 0 -to- -144dB attenuation for all inputs to the digital
   mixer, the 0 -to- -63dB attenuation of the analog DAC, and the +18 -to-
   -63dB attenuation/amplification of the analog ADC. (3) All gtk "scale"
   widgets have dB legends; the "PageUp" "PageDown" keys allow rapid
   movement between the marked levels. (4) Got rid of myriad compiler
   warnings and other minor fixes across codebase.

http://nielsmayer.com/envy24control/envy24control-0.6-to-1.0.patch
(patch to 'envy24control' from GIT trunk of alsa-tools)
http://nielsmayer.com/envy24control/envy24control-1.0.tar.gz
(full directory, just follow README directions to build/install)
http://nielsmayer.com/envy24control/envy24control-1.0-fc12-x86_64.tar.gz
(x86_64 binary that should work on fedora12 and equivalent OpenSuse release)
http://nielsmayer.com/envy24control/envy24control-1.0.README
(summary of changes from 0.6.0 to 1.0.0)

In helping move this upstream, any testing results or comments on my 1.0.0 release of envy24control would be appreciated. In particular, I'd like some assurance that the dB markings on sliders are correct (compared to values reported by 'alsamixer'). In particular, looking for testing with following devices:

M-Audio Delta 1010
M-Audio Audiophile 2496
TerraTec EWS 88MT
TerraTec EWS 88D
TerraTec Phase 88
Hoontech SoundTrack DSP 24.

See updates to envy24control here:
http://nielsmayer.com/envy24control/?C=M;O=D

http://mudita24.googlecode.com is the page for my fork of envy24control(1) although I hope to submit it for acceptance by ALSA once some contributions by Tim E. Real are finalized.

This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.