From: John C. <j4s...@bi...> - 2004-08-15 03:45:45
|
On Saturday 14 August 2004 04:13 am, Werner Schweer wrote: > On Friday 13 August 2004 23:52, Fernando Pablo Lopez-Lezcano wrote: > > On Fri, 2004-08-13 at 14:17, Robert Jonsson wrote: > > > Werner, > > > About the recent discussion about lousy functionality under 2.6 it was > > > discovered that performance could be drastically improved by setting > > > the scheduling priority for the jack-thread to a higher number. > > > > > > I have a number of open questions about this. > > > > > > For starters I was wondering if this priority is not supposed to be set > > > by jack, and this being the reason it was set to a very low value? > > > > It is supposed to be set by Jack. > > thats right. MusE checks the Jack thread for SCHED_FIFO. If not, > MusE sets SCHED_FIFO and priority. This is only a workaround for > erratic 2.6 behaviour. > I just installed a new glibc (2.3.4-20040701) and the bug disappeared so > i believe its related to the nptl libray. > > > > If this is not the case, are there any drawbacks to setting the value > > > to, say 50 instead? > > > > At least one I can think of, the watchdog process within Jack will not > > work. An error in Muse could hang the machine because the watchdog > > process would not be scheduled (I'm positive the watchdog process is > > running with a priority higher than all other Jack threads). > > the watchdog thread should have the highest priority of all threads. > MusE sets up a watchdog thread of its own with the highest possible > priority. > There is another RT thread in MusE to schedule midi events. This > Midi thread must have higher priority than the jack thread. If not > you get some midi events quantized to the jack period size. > It seems like a bit of a paradox to expect more than one realtime thread to perform as realtime (by whatever definition). Wouldn't there be some sort of contention once you hit N processors +1 threads? > > > And thirdly, a fundamental question: I didn't dig to deep into this and > > > don't fully understand the implications but why is a thread needed in > > > this context? Jack is callback driven, right? Is the thread just > > > hanging on the callback or how does it work? > > > > The audio thread that has the callback function has to be running with > > realtime priority, otherwise dropouts would occur. > > jack starts a thread. The jack callback is called from this thread > context. > > /Werner > > > > > ------------------------------------------------------- > SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media > 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 > Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. > http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 > _______________________________________________ > Lmuse-developer mailing list > Lmu...@li... > https://lists.sourceforge.net/lists/listinfo/lmuse-developer |