Realtime group scheduling doesn't know JACK

I must step in here, firstly I look after multimedia apps and libs for openSUSE and the largest and most prominent packaging "todo" I have, is a jack that just works when installed. I'm also a hardware person majoring in games, controllers and juke boxes.
Jack needs RT for latency in response time. Jack is basically a bunch of virtual wires which connect the virtual desks, effects, etc. which make up a very nice and usable array of professional audio applications that run on linux. We all know what happens if we use a defective lead to connect our dvd machine to the fancy home theater system we just bought, the same thing happens to jack if it's looking after a couple of synths, a few filters and an external midi keyboard. My pet package rosegarden won't even start jack if it (jack) doesn't have realtime rights with the kernel and as a result rosegarden doesn't produce sound.
On the other side of the card, one doesn't mix professional audio processing with servers and the like, my celeron E1200 1 gig ram and only one ide port with my dvd writer and only system hard drive hanging on it (saving up for a sata drive to clear a major system bottle kneck) is certainly not suitable as a professional anything workstation but it produces clean audio as long as nothing else is hogging I/O with a crappy HD onboard sound which uses up system resources (I've at least got a mother board with potential the E1200 is the slowest cpu it will work with). Audio is slow in frequency and doesn't have high bandwidth requirements like for example gaming 3D which is taken care of by the GFX card. A professional sound card has the audio processing and audio buffering (ram) to take the load of the system the same as a high end gaming graphics card does and I must add that the providers of this type of hardware are generally happy to stay in the unfree but profitable world of microsoft, have you ever heard of high end audio or video hardware without a shiny windows installation dvd. What the blinded by windows masses don't realize is linux has these drivers already built in to the kernel mostly and rosegarden for one has a directory full of hardware midi drivers and if you don't find yours, the developers will try their damndest to make one for you.

The only blot on linux's copybook is the connecting cables - Jack having to disconnect and reconnect (please don't take this as an intellectual statement, it's simply an attempt to simplify my explanation) to accommodate daemons with higher privileges that it isn't fast enough to keep up with and on a multiplexed system RT is a major privilege which gives the application the power to screw up kernels scheduling of other software. Linux being traditionally a server work horse and relatively new to the role of PC is naturally cautious about allowing things that can cause denial of service problems. I innocently asked about jacks rpm writing to "/etc/security/limits.conf" on installation and was met with shock from the old school packagers, well just one actually who stated "I'd veto such abuse of the audio group" and would be likely to do so if I attempted to submit such a jack to factory. It was also hard to explain that jack was started by various user programs and not the user itself. We must also take into account the fact that jack can use the network as well which makes it more of a security threat (Don't tell but I sneaked a jack2 replacement for jack without remembering the aforementioned). At the end of the day though jack isn't going to be used on an apache production server but on a box that has that side of linux "dumbed down"

Jack needs RT to enable it to respond in real time to simultaneous requests from the likes of rosegarden and hydrogen otherwise the drummer will be out of sync with the rest of the band or worse still jack will become overwhelmed by the quantity of tasks that it's waiting to perform and buckle under a denial of service attack from the kernel it trusts and just freeze up, this really happens. and the users that have had linux fervently pushed upon them will shuffle back to windows and qbase be it pirated or not, the poor have no conscience about cash before copyright whereas if jack ran in real time, linux would have converted criminals into honest people.
With my hardware hat on, most audio latency problems like "echos, pops, squeeks, pauses" can be taken care of by heaps of ram or very efficient virtual memory, a couple of raid stripes but what cannot be taken care of by buffering is jacks role of conductor in the orchestra of impatient audio apps.

It's refreshing and reassuring to read the comments of the libcgroup developer, there is a light at the end of the tunnel and I must research this further, maybe we can have a "working out of the box" jack in openSUSE 11.4.
I hope my story has enlightened the doubters as to why jack needs realtime, why? for the furthering of the open source cause, that's why.
I'm speculating that libcgroup has fresh linux blood in it that cares about linux the PC as much as linux the server.

I can assure the doubters that jack needs RT privileges due to it's role as a server, the word server as in X server not as in samba server, which connects a network of applications to create audio compilations, the word "network" not to be confused with the network which is translating my key presses to this web page but more like a network of business that compliment and help each other. Jack doesn't need RT like a custom built car needs custom parts and paint work but like a tractor needs special wheels to pull the plough through the field.