[PlanetCCRMA] jack_capture with jack 1.9.4 complains about nice value of "-10", wants "-20"

[Fernando Lopez-Lezcano]

On Tue, 2010-06-22 at 21:11 +0200, Kjetil S. Matheussen wrote:
> Niels Mayer:
> >
> > However, for jack_capture-0.9.40-1.fc12.x86_64 wants a nice value of "-20"
> > but only gets "-10" .
> >
> > Is this behavior in jack_capture a hold-over from Jack 1.0 days, and a
> > potential incompatibility for jack2?
> > [I'm using jack-audio-connection-kit-1.9.4-1.fc12.ccrma.x86_64  with
> > "@jackuser - nice -10"]
> > ...............
> > coggie-161-~> jack_capture
> > Recording to "jack_capture_01.wav". Press <Return> or <Ctrl-C> to stop.
> > Warning. Could not set priority to -20, only -10.
> > You probably have wrong nice value in /etc/security/limits.conf.
> 
> There are two processes in jack_capture which are a little bit
> more important than normal processes such as GUI processes etc.
> 
> One of them is the process which writes to disk. This process
> only gets a higher nice value in case more than half of the buffer
> is used, which should normally never happen.
> 
> The other process is a process which monitors the amount of
> buffer which is used. In case the amount of free buffer is at any
> time lower than the initial amount (default is 4 seconds), a
> little bit more memory (two blocks) is allocated automatically
> and added to the buffer.
> 
> And it is this second process which is responsible for printing that
> warning.
> 
> This process is probably not so important that it should run
> with the lowest realtime priority, because that's the priority
> processes such as midi event handlers use, and allocating memory
> using the lowest realtime priority could prevent tasks such as
> midi event handlers to respond fast enough.
> 
> Instead, it tries to run with the highest normal priority, i.e.
> the lowest nice value, since it is a very important task, much
> more important than perhaps all other tasks not running realtime. 
> And it is also a very lightweight process, so it should not
> cause the GUI to stutter for instance.
> 
> However, for some reason, fedora only allows normal processes
> to set nice value to -10! That doesn't make very much sense
> if you are allowed to set processes to run with a realtime
> priority. So that's the reason for the warning. The solution
> to get rid of the warning is to fix the /etc/security/limits.conf
> file.

Or to query what is the maximum negative SCHED_OTHER priority you are
allowed to use and use that (I know that is possible with realtime
SCHED_FIFO, you can query what are the max and mix values allowed,
hopefully that would also be possible with SCHED_OTHER). 

Stock Fedora does not allow users to use the highest value for
SCHED_FIFO either. 

-- Fernando