On Wed, Jul 28, 2010 at 12:57 AM, James Morris <[email protected]> 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 [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
