Description of problem:
envy24control doesn't work correctly, either using M-Audio Delta 66 or Terratec DMX6Fire24/96. Under the "Digital Mixer" meter on the left, there's a button "Reset Peaks" which doesn't do anything because envy24control's metering isn't showing or holding any peak levels, as it should.
Without holding the peak-levels, the meters flash into the "orange" and "red" zones too quickly to perceive. This makes this utility sort of useless for it's intended purpose -- setting input levels in the ADC's for best dynamic range, but without clipping.
The fact that the "Reset Peaks" button is there indicates that a "peak hold" functionality is part of this application, however, it is either unimplemented or not working. It is a bug to have non-working functionality that is expected in an application; alternately it is a bug to have a button indicating that functionality exists in the application when the button acts as a No-Op.
(It would be inappropriate to fix the bug by removing the button, however, since such metering functionality is an essential part of this application).
Version-Release number of selected component (if applicable):
gnulem-128-~> rpm -qf /usr/bin/envy24control
Steps to Reproduce:
1. Run 'envy24control' with live signals on inputs to snd-ice1712 soundcard
2. Attempt to adjust levels, and note it's difficult to tell when clipping because "peak hold" functionality isn't working.
3. Click "Reset Peaks" (even after clipping has happened) and nothing happens.
Recordings with clipping.
A meter that stays "red" if clipping has occurred, and is bright and noticeable.
Clicking "Reset Peaks" will clear this indication, and will allow for ongoing clipping to be detected and corrected.
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).
* To see what the new meters look like.
* 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.
* 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
>> 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
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.
(patch to 'envy24control' from GIT trunk of alsa-tools)
(full directory, just follow README directions to build/install)
(x86_64 binary that should work on fedora12 and equivalent OpenSuse release)
(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://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:
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.