On Wed, Jul 28, 2010 at 12:57 AM, James Morris <james@email-addr-hidden-art.net> wrote:
> Have to say, the bright-green and cadmium-yellow-deep combination is
> particularly disgusting!
> ...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:
http://www.wolframalpha.com/input/?i=cadmium+yellow+as+a+color
Personally, I thought this one
> http://jwm-art.net/Screenshot-Envy24Control-MonitorInputs_bg_002100.png
would leave some people wondering about monsters and dark closets for
whatever lurks behind the meters when no sound is displayed. :-)
> http://jwm-art.net/Screenshot-Envy24Control-MonitorInputs_bg_243620.png
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
http://en.wikipedia.org/wiki/Colony_collapse_disorder 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 very sluggish.
> 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
this.
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.
> > What's the CPU usage like running regular /usr/bin/envy24control ?
>
> Negligible.
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
https://bugzilla.redhat.com/show_bug.cgi?id=602903#c3 for details.
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?
Niels
http://nielsmayer.com
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Thu Jul 29 00:15:02 2010
This archive was generated by hypermail 2.1.8 : Thu Jul 29 2010 - 00:15:02 EEST
