[LAU] The Many Ways of Pam Limits...

[Jack O'Quin]

On Mon, Jul 20, 2009 at 7:21 AM, Paul Davis<paul at 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.

Despite the fact that negative nice values are ineffective for
achieving solid realtime audio, I doubt we'll see many distributions
jumping into the role of discouraging that style of programming.

Most distribution developers see their role as packaging Linux
applications in a form that makes them easily accessible to end users.
 They generally avoid highly technical discussions about "how those
applications should be written".

If enough users want to run "nice-audio" applications, they are likely
to enable that behavior.  Why shouldn't they?
-- 
 joq