<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Dec 8, 2012 at 2:19 PM, Paul Coccoli <span dir="ltr"><<a href="mailto:pcoccoli@gmail.com" target="_blank">pcoccoli@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Sun, Dec 2, 2012 at 8:01 PM, Paul Davis <<a href="mailto:paul@linuxaudiosystems.com">paul@linuxaudiosystems.com</a>> wrote:<br>

> nice has absolutely nothing to do with this, and if it has any effect, it is<br>
> accidental and should not be relied on.<br>
<br>
</div>I know that's your stock answer whenever someone mentions nice, but if<br>
the OP is talking about SCHED_OTHER processes, nice does play a role.<br></blockquote><div><br>nice alters the behaviour of scheduler with respect to SCHED_OTHER tasks using an algorithm that is (almost) completely irrelevant for programs that do very little interaction with the user and use most of their CPU time streaming media. <br>
<br>applications that stream media should either (a) use enough buffering that they do not run into xruns with respect to the delivery endpoint or (b) use SCHED_FIFO/SCHED_RR (c) both. using nice is a bandaid that simply masks design problems, if in fact it has the right effect at all.<br>
</div></div></div>