Ghee: >> - 6604602 - mixer applet should poll less frequently. This patch is >> a bit smart and reduces the number of times we poll from 10 times >> a second to every 1.5 seconds. If the mixer applet notices a change >> has been made, then it will update 10 times a second for 10 seconds >> after the last time it changes. This way the mixer applet updates >> frequently when the user is actually changing the value, but doesn't >> update often in the normal case. > Update once every 1.5 seconds is still too aggressive when user is not > using it. That is, once I log in, it just refreshes at whatever rate it > is even > if I have have done nothing to the sound/mixer. I think a default on that > would be no harm to be set to 5 seconds or more.
I disagree. When you change the volume, you do want to see the mixer applet refresh. I notice that if I set the delay to more than 1.5 seconds that it starts to make me wonder, "why isn't the applet updating, what's broken?". We could perhaps up the delay to 2 or 2.5 seconds, but the delay starts to get much more noticeable at these higher timeouts. When you actually change the volume (e.g. in gnome-volume-control or sdtaudiocontrol), most users don't twiddle the knobs for over 5 seconds. A delay of that long wouldn't be good because you don't want it to wait until the user is done making changes to start updating. > From the case it has noticed a change, I think your suggestion is great! > But I don't know/understand enough how the changes is being trigger off, > can't make better suggestion. As Jan points out, we could use SIGPOLL, but this is ugly since it would require that the mixer applet become aware of the SunAudio device. This breaks the model that the GStreamer plugin should be the only place aware of the actual device specifics. Also, this approach would be tricky to get right since we are moving towards using OSS sometime early next year. So the mixer applet would need to know when SunAudio is being used and only listen to SIGPOLL in that case. We wouldn't want to listen to SIGPOLL if OSS is being used. In my opinion, this patch does improve things and reduces the amount of time the mixer hits the CPU by a factor of 10. This improves things in the meantime while we wait for OSS to integrate. Unless someone has a great suggestion on how to further improve things, I think we should hold off on doing anything further until OSS integrates. At that time, we should focus on making sure the performance is reasonable with OSS since SunAudio will eventually be going away. Brian
