Originally, I did not check to see if qjackd was /actually/ running in realtime priority. Honestly, the thought never struck me. Anyway, I dl’d htop (yet another non-pre-install app on UbStud) and ran it to the following results: I’ve got jackd running and showing PRI numbers at -11 and -21 (qjackctl running at -10). These were the lowest numbers in the list. I did not see any -51 processes, so Jack has the highest priority. Whether its -99 or -21, it still gets priority. The nice number was not set as low as it could go, but I was able to change it easily which made my xruns start screaming by a lot faster. Sorry, one more note: this is also on the Intel sound card. When I put in my M-Audio Fast Track, which is a USB 1.0 device, I’m getting only 8 msec lag and I don’t get xruns unless I load a bunch of windows on my cube and start rotating in compiz while qsynth and hydrogen are under light Rosegarden control (3 instruments in MIDI). The aggrevating part about this is that I have to break out my external and heaphones or speakers even if I want to just play with drum beats for a little bit.

The *nix kernel was built with stability in mind, so there has to be a gradual evolution of the kernel into a true swiss army knife kernel. On a server, I want that stability of my kernel to not fritz out and possibly preempt my rendering a spot of video with a cute sound which lets me know that tea’s ready. I know that’s a bit extreme, but would be nice to have as a switch to turn on if I’m needing to “break” that stability and my streaming videos be damned if they try to interfere with my (somehow miraculous) Aki Takahashi-ish solo at the end of a recording… yeah right.

I like the idea of having a more monolithic kernel as it is faster and more stable; but, yes, this would mean that we are out in the cold until real time scheduling is a reality in a later evolution of the kernel. If it is left in, then developers will continue to use the lsm as a crutch and not work towards developing a real fix. This leaves us with older kernels for a little while until this happens. The other option would be to fork the kernel development for a possible merge later down the road, but that ain’t gonna happen.

…I wish Haiku would gain some steam and hurry up with development. While I’m at wishing, I wish I had a cheap, high peformance renewable energy source for my car.

I can not get any scheds above 51

jackd – supposed to be rtprio=70
/etc/security/limits.conf
audio group apps supposed to limit to 99

and yet freewheeling is continuously crashing unless I run everything as root.
htop shows no audio related processes with priorities higher than 51.
In fact many other non-audio and system processes have that magic limit -51 – leaving audio to compete with them.

googling has brought no answers to this new problem yet.
It’s Torvalds who wants the lsm (securities) modules out of the kernel in favor of static-built-in alternative with no option to build as a module.
This kind of leaves us Audio users high, and dry untill there are workable alternatives.
So far the built-in way is not working as well as the realtime.lsm module has worked in the past.
What do you think about this issue?

JWM