Re: [LAD] [LAA] announcing envy24control, mudita (*) edition.

On Wed, Jul 28, 2010 at 12:57 AM, James Morris <james(a)jwm-art.net> wrote: I had to look that one up: http://www.wolframalpha.com/input/?i=cadmium+yellow+as+a+color Personally, I thought this one would leave 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 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: ... 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. 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