nescivi wrote: > > Thursday, January 13, 2005, 11:10:58 AM, you wrote: > JB> 2. Xruns created by battery polls: I don't know if this is the same > JB> problem that you are experiencing, but I used to run the gnome > battstat > JB> applet on my gnome panel. It took me a while to diagnose that this was > JB> causing a lot of xruns, presumably every time it checks the battery > JB> status. You might want to check that you don't have any status applets > JB> running. You might also want to check that you don't have the kacpid > JB> bug (check google for this). > > This is probably the reason that I get xruns, and I suppose I should > find a solution for that (does anyone else have the problem on a > ThinkPad R51, 2.4.26 (debian) kernel?) > > But the main thing that is annoying, that even when I have no audible > problem with this, QJackCtl (the GUI) is totally overloading the > system, as it wants to tell me constantly about this xruns. > I would like to know whether it would be possible to make it so that > the GUI would not get a signal for each xrun, but instead, if they > happen too often, only a signal once in a while. I think it should be > possible to create something in the interface, so that it only updates > once every 25 ms or 50 ms. That way it will not overload the system. > That way, I would still get the info from QJackCtl that there are a > lot of xruns, but I will still be able to do something about it, > without getting frustrated trying to move the mouse pointer around to > do so. I mean, I will not be able to read the info about each xrun at > the precise ms. so it can come a bit later and grouped. GUI updates > when they happen too often take a lot of processing time, so it would > be better to limit them in this case. > I'll see what I can do about, like tracking the XRUN frequency/rate and bypass the display (e.g. messages window) if it gets too high. That assumes thats the cost of rendering the XRUN messages lines that is hosing qjackctl. Bye now. -- rncbc aka Rui Nuno Capela rncbc@xxxxxxxxx