Le Wed, 1 Jun 2011 13:49:06 +0200, Nick Copeland <[email protected]> a écrit :
> > I might get flamed for this however GUI should not really be run with > rt priority, that is an honour for the DSP engines. There are some > reasonable arguments however for leaning on the scheduler with renice > for the user interfaces to give them a bit of a bias over other > system operations. Admittedly a big topic since the GUI probably sits > on top of the windowing system anyway. > > So I have not used renice on graphics/GUI processes but I have worked > on systems where the RT DSP code is happily chewing up 75% of CPU to > churn out 32 unified synth voices and the GUI response can then give > a bad impression of an application. Renice will help the sometime > intensive graphics manipulation code (which is surprisingly close to > DSP anyway if you are doing subpixel image transforms with shadow > rendering) to get a little more of the now starved system resources. I think than the wm in use can maybe have an impact on the graphical responsiveness. When running a single mono processor, I get up with jack at more than 95% CPU, this with gentoo running a rt kernel, fvwm and the fvwm-crystal theme. Sometime, the graphical response was a little bit slow. A few times, the wm was frozen during one or 2 seconds, even the cursor. But the audio process in JACK was just fine and without any xrun. I was very surprised, this was amazing, like in window$, but without the crash -:) I cannot imagine to do the same with kde or another wm, in fact I don't know if it can be possible. Now, on a multi-processor, I never experimented such a slow down of fvwm, but I didn't use jack with such a high load than before. Dominique -- "We have the heroes we deserve." _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
