linuxaudio.org

Le Wed, 1 Jun 2011 13:49:06 +0200,

Nick Copeland  a écrit :
>

quoted text
> 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

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev