20 Jul
2009
20 Jul
'09
10:21 a.m.
On Sun, Jul 19, 2009 at 11:17 PM, michael noble<looplog(a)gmail.com> wrote:
On Mon, Jul 20, 2009 at 7:15 AM, Paul Davis <paul(a)linuxaudiosystems.com>
wrote:
there are a few applications out there that seem to believe that you
can improve audio performance (i.e. less dropouts under load) by
changing their own nice value. this represents a complete
misunderstanding of the differences between conventional Unix
scheduling ("SCHED_OTHER") and realtime scheduling like SCHED_FIFO and
SCHED_RR. using nice can, under a few circumstances, make a
difference, but its use basically means that the developer(s) really
don't understand what the issues are.
presumably some distros believe that their version of limits.conf
should accomadate this kind of misconception. i don't think that
limits.conf should be specifying a nice value, at least not in
connection with audio/music applications that inherently need realtime
scheduling.
The nice value is irrelevant. Anybody attempting to use nice(2) to
improve realtime performance doesn't understand what they are doing.
It is very unfortunate that this has crept into so many limits.conf
examples.
Can you expand on this a little? Are you saying there is absolutely no need
to include a nice setting in limits.conf? Is this just some wacky tradition
that has been handed on between linux audio distros and metadistros? Don't
get me wrong, you probably know better than I, but it'd sure be nice to hear
an informed reason to abandon this practice.