On Wed, Jul 28, 2010 at 12:57 AM, James Morris <james(a)jwm-art.net> wrote:
Have to say, the bright-green and cadmium-yellow-deep
...especially on that green background. IMO the darker green
background should be less prominent, a much darker green.
I had to look that one up:
Personally, I thought this one
some people wondering about monsters and dark closets for
whatever lurks behind the meters when no sound is displayed. :-)
is a good
compromise -- I'll change the code to that unless someone
has a better color choice, or the colors are found to be nauseating to
those with http://en.wikipedia.org/wiki/Tetrachromacy
... or it turns
out to be a factor contributing to
as bees hurl
themselves against LCD screens due to the irresistible draw of the
bright green and cadmium-yellow (sounds like that could form the basis
of the next Monsanto misinformation campaign...).
Also, you mentioned there was a problem with CPU usage and sluggish
response. I haven't heard of any other complaints along these lines,
so i'm wondering if you did something to resolve the issue, or if you
might be able to do some more debugging:
CPU up to 99% here as soon as any audio plays and GUI
Delta 66 AMD64 Gentoo.
The levels start off looking as they should, but
appear to accumulate
until peaked out after a couple of seconds. This is when it gets
sluggish - switching tabs will take a second at minimum. Hitting the
reset peaks buttons resets the levels but they immediately peak again
(ie the accumulation stays). After stopping the audio playing (sox
play on command line) the peaks take a couple of seconds to drop, and
CPU usages falls back to relatively normal levels.
What X server are you running, or rather, are you running on a
particularly slow, totally unaccelerated server? Or an ATI Catalyst
(closed-source) server which is known to have poor X performance. Is
the CPU usage coming from the new 'envy24control' or the X server? If
it's in envy24control -- could you find out where or what it's doing?
Other than the distro, I too have Delta66 and AMD64 so I would hope
there wouldn't be these kind of problems/differences on something like
Anybody else seeing anything even remotely like this... it sounds like
something has gone horribly wrong.... IMHO this should significantly
lower CPU usage, not raise it.
CPU usage like running regular /usr/bin/envy24control ?
The CPU usage is relatively low, but the overall X resource usage (and
interrupts and many I/o's to the soundcard) is unnecessarily high. But
may not become noticeable until you actually load up your machine with
"foreground" tasks -- this is supposed to be a utility you can leave
running in the background and not worry about . See
In addition to X resource use, the old envy24control also generated a
lot of I/o and interrupts :
- gtk_timeout_add(40, level_meters_timeout_callback, NULL);
- gtk_timeout_add(100, master_clock_status_timeout_callback, NULL);
- gtk_timeout_add(100, internal_clock_status_timeout_callback, NULL);
- gtk_timeout_add(100, rate_locking_status_timeout_callback, NULL);
- gtk_timeout_add(100, rate_reset_status_timeout_callback, NULL);
Now it no longer tries refreshing up to 10 meters 25 times a second,
along with an additional 40 interrupts per second to individually
check the clock status, rate locking status, and rate reset status --
which hardly ever change anyways.
Note that this is totally wrong to begin with, the new code just makes
it less wrong, calling all of them 10 times a second in a single
callback. Rather than all those multiple separate calls. (Then again
-- maybe that's what's causing the sluggishness you're seeing? )
Why can't checking for changes at the ALSA level to "rate reset" "rate
locking" "clock status" and "master clock status" happen without
needing to poll for such changes. Isn't there a way of setting up a
select() on file-descriptor?