On Mon, Jul 20, 2009 at 7:21 AM, Paul Davis<paul@xxxxxxxxxxxxxxxxxxxxx> 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
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
