>> * Jack O'Quin <[EMAIL PROTECTED]> wrote: >>> One major problem: this `nice --20' hack affects every thread, not >>> just the critical realtime ones. That's not what we want. Audio >>> applications make very conscious choices which threads run with high >>> priority and which do not.
> Ingo Molnar <[EMAIL PROTECTED]> writes: >> how much did this problem affect your test? Could the source of the 500 >> msec delays be the non-highprio components of the test that somehow >> became nice --20? Jack O'Quin <[EMAIL PROTECTED]> writes: > Probably, the best way to tell would be patching JACK so it uses > nice(-20) instead of pthread_setschedparam() for the realtime threads. > As a hack, that looks easy. I'll build a working directory with just > that change, so we can experiment with it better. Bah! Nothing is ever as easy as it looks. According to the manpage, nice(2) is per-process not per-thread. That does not give the granularity we need. Is that correct? If so, I can't think of any way to make this work. Suggestions? We need to allow both realtime and non-realtime threads in the same process. Anything less would require an enormous rewrite for most audio programs, an unreasonable thing to ask. -- 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/
