Con Kolivas <[EMAIL PROTECTED]> writes: > Jack O'Quin wrote: >> I'll try building a SCHED_RR version of JACK. I still don't think it >> will make any difference. But my intuition isn't working very well >> right now, so I need more data. > > Could be that despite what it appears, FIFO behaviour may be desirable > to RR. Also the RR in SCHED_ISO is pretty fast at 10ms. However with > nothing else really running it just shouldn't matter...
That's the way I see it, too. > There is some sort of privileged memory handling when jackd is running > as root as well, so I don't know how that features here. I can't > imagine it's a real issue though. We use mlockall() to avoid page faults in the audio path. That should be happening in all these tests. The JACK server would complain if the request were failing, and it doesn't. How can I verify that the pages are actually locked? (Even without mlock(), I don't think I would run out of memory.) -- joq - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
