20 Jul
2009
20 Jul
'09
11:41 a.m.
On Mon, Jul 20, 2009 at 7:21 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.
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