> Paul Davis wrote:
> what are those arguments?

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.

> which is why ardour's default disk i/o buffers are *FIVE SECONDS* long (we
> really have seen delays of this length when reading from disk!).

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).

> SCHED_OTHER are targetting console-driven applications that do varying
> balances of disk i/o, computation and user input/output. they really
> don't address the situation of an app that needs to redraw with a
> relatively fixed interval on screen, nor do they provide any actual
> scheduling guarantees,

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.

> Robin Gareus wrote:
> How many audio apps support 'rtprio' directly (without JACK)?

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.

> ..and how many pro-audio users do use this software [...]
> I bet the number is zero.

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