Andrew Morton <akpm@xxxxxxxx> writes: > Thanks everyone. It does start to look like a CPU scheduler problem. > > Other possibilities are that > > a) Jack is doing something unusual and is triggering some bug in 2.6 > which causes the kernel to go into an extended sulk. Or > > b) Some change in 2.6 is triggering a bug in Jack, causing Jack to go > into an extended sulk. JACK is a heavy user of pthreads. NPTL is another difference between 2.4 and 2.6. I have not heard any reports of problems with the interaction of NPTL and JACK, but this certainly remains a possibility. How can we zero in on what's really happening? > Question: have these problems been observed with other audio apps? With a > similar severity and frequency? I don't run non-JACK audio applications much. My impression is that there are fewer problems. They typically don't require so many thread dispatches per buffer, and they often use much bigger buffers because low latency is not always important. > "Jack O'Quin" <joq@xxxxxx> wrote: > > hm, now here was me thinking the name meant "audio jack" ;) It does. The acronym is "JACK Audio Connection Kit". Paul Davis is the primary author. The name was selected before I started working on it. :-) > > Unfortunately, if you run the JACK daemon as root you must also run > > all its clients that way. > > Maybe Jack could switch UIDs and drop privileges after acquiring rt policy? The server continues to need realtime privileges even after startup, when new clients connect, for example. A lot of work has been done in this area. With 2.4 the preferred solution was capabilities. With 2.6, we have been experimenting with an LSM for realtime privileges. The new Security Module mechanism is a big step forward. Here's a (very) preliminary version... http://www.joq.us/realtime -- joq
