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 don't see any point to advise not giving the audio group access to this option since you can argue that, whilst it does not do anything very spectacular, it is not going to damage system integrity any further than the already active RT priority rights. Low latency audio systems are all about tuning and this remains one of the tools available to you. Regards, cnik. "we have to make sure the old choice [Windows] doesn't disappear”. Jim Wong, president of IT products, Acer

The argument is that rendering images, a part of the GUI, also requires chewing up a lot of CPU. These processes aren't involved in lots of disk IO, they can be manipulating images with either 2D or 3D transforms - as I said, it is pretty similar processes to DSP, it is intensive. The time slicing scheduler gives preference to runnable processes that are not using all of the CPU that is given to them and since the image manipulation code is doing exactly that when elements of the image are being moved then its priority pushes it down the list of runnable process - it may have to wait longer to carry on the rendering code. There are many aspects to a responsive system: you seem to be arguing that the only relevant one is the audio processing (which includes the disk subsystem). All I am saying is that when you use the mouse to pick up an element in the GUI and you move it that you then also want to see it move. RT scheduling and big buffers are the tools you use to maintain the audible components and renice is almost the only sad little thing available for all else. Ardours disk thread is sched_other. When you wait seconds for IO which finally arrives then your process is pretty much guaranteed, by the scheduler, to be the next process to take the free CPU as your priority improves as your waiting time goes up. A number crunching GUI does not have this benefit since it has not sat around waiting for the system to do something. Applying a renice will move it up the queue (although even at renice -20 it would not pre-empt the typical priority of this disk process). I was not even considering the effects of time scheduled actions in a GUI, simply tracking the interactions of the user with their interface when the system is under stress. I think we may have mixed the conversation. Ralf asked if this option should even be in the limits configuration. My answer, offlist, was that there were some potential uses and that since you can already hose an otherwise perfect system by giving a user permission to access to RT limits that there is no adverse effect of keeping this one. If there are good arguments not to have this as a limit for the audio group then have the distributions remove it, by all means. I don't see the negative side it being provided, it remains a tuning tool. I would have expected most of them to implement but that is just an opinion, I am not big on having to rely on other libraries for features that I consider crucial. As stated above, user experience is defined by system response, that includes the audio and the video. Bristol has these as separated processes and this is one of very few ways to control the its GUI CPU profile. I would not contest that. I am not sure how rtprio and having renice in the limits config is really related to jack though. Regards, nick

Le Wed, 1 Jun 2011 13:49:06 +0200, Nick Copeland <nickycopeland(a)hotmail.com> a écrit : 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."

On Wed, 2011-06-01 at 07:27 -0400, Paul Davis wrote: You'll read such 'help' thousands of times when you're subscribed to regular distro users mailing lists or on non-audio Linux forums. I always post http://www.jackaudio.org/linux_rt_config when I read such recommendations. Since people usually are using Jack by a package, when thy use real-time audio apps IMO it's ok to include it to a Jack package, anyway, IMO there should be a dependency setting without nice and with memlock. I just want to inform about this issue. Coders and package builder might not be informed about what happens on non-audio users lists and forums. FWIW very often there are recommendations to _avoid_ a kernel-rt, since a distros 'default', 'desktop', 'generic' kernel should have the same capabilities and the kernel-rt should have disadvantages. The resume then could be, that people wonder, that they can't use Linux for complex audio sessions. IMO it doesn't make sense to package audio and MIDI applications without packaging the environment to use those apps. Users launch their package management GUI and install audio apps, they do not read FAQs, manuals. Then they make some tests recording two tracks. Later, when they do a real session, the issues start. -- Ralf

On Wed, 2011-06-01 at 18:10 +0200, Ralf Mardorf wrote: Alas, the stock Debian kernel these days does *not* use "Low Latency Desktop" :( I don't know if derivatives have followed suit or not... -dr

On Wed, 2011-06-01 at 14:40 +0200, Robin Gareus wrote: Hi Robin :) somebody on the Debian users list send this to me and he seems to use Jack by a package ;). -- Ralf