Red Hat Bugzilla – Full Text Bug Listing
|Summary:||envy24control "Reset Peaks" button nonfunctional; metering shows no peaks|
|Product:||[Fedora] Fedora||Reporter:||Niels Mayer <NielsMayer>|
|Component:||alsa-tools||Assignee:||Tim Jackson <rpm>|
|Status:||CLOSED WONTFIX||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2010-12-03 08:55:21 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Niels Mayer 2010-06-10 20:41:22 EDT
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 alsa-tools-1.0.22-1.fc12.x86_64 How reproducible: Always. 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. Actual results: Recordings with clipping. Expected results: 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. Additional info:
Comment 1 Niels Mayer 2010-07-12 17:29:25 EDT
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!
Comment 2 Niels Mayer 2010-07-12 17:34:49 EDT
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.
Comment 3 Niels Mayer 2010-07-16 03:21:03 EDT
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
Comment 4 Tim Jackson 2010-07-16 04:55:05 EDT
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.)
Comment 5 Niels Mayer 2010-07-25 12:13:50 EDT
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)
Comment 6 Niels Mayer 2010-07-25 12:26:10 EDT
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.
Comment 7 Niels Mayer 2010-08-05 01:10:37 EDT
See updates to envy24control here: http://nielsmayer.com/envy24control/?C=M;O=D
Comment 8 Niels Mayer 2010-08-28 17:40:56 EDT
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.
Comment 9 Bug Zapper 2010-11-03 09:20:31 EDT
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
Comment 10 Bug Zapper 2010-12-03 08:55:21 EST
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.