Realtime group scheduling doesn't know JACK

part of the fun is that it's hard to know ahead of time if you can afford large buffers or not.

when you are building and configuring a system, how do you know if the output is going to a recorder (where latency is acceptable), or to speakers (where it's not)

since there are some cases where you need the real time response, why not use that setting all the time rather than having one set of settings if you are going from live to live and a different set of settings if you are doing something where latency is acceptable?

> To solve the problem of buffer underruns, you need to increase the size of your buffers. If you cannot increase the size of your buffers due to latency concerns, or if you have hardware limitations, _then_ I agree you need realtime. But it seems to me that the vast majority of "I'm getting xruns with jack, I need realtime!!"

No.

With Linux without realtime configuration you can't make your buffers large enough to avoid xruns, unless they are very large, because your not able to control your latencies.

That's the point. Realtime gives you control over the latencies. Of course Linux can't give you hard realtime, but certainly the level that Linux can provide when properly configured is enough for audio production.

> In some of my research work, we deal with streaming data from various capture cards at relatively high rate (up to 2Mbit/s). We write it directly to disk on a relatively busy system that can go out to lunch for 500ms or more. The only time I ever had to invoke SCHED_FIFO was with some poorly-designed USB hardware that only had a 384 byte buffer. Now we design our hardware with at least 1MB buffer and the kernel scheduler is no longer a concern.

Does your data corrupt and get nasty artifacts when you get latencies up to 500msecs? Because that is what happens with audio streams. You not just dealing with recording data to disk, your interacting with the real world that won't be able to wait on your computer to respond...

Yes, your perception is wrong. To build professional audio systems you need to care about latency nearly all the time. If your point was "JACK is not necessarily the right choice for playing a 'Ding!' sound when I receive new mail", you have our agreement. But that's not what JACK users are using it for.

It all matters, right down to when I hit a button I want it to take effect immediately. I understand as a programmer that it can't happen literally the moment I press the button, but as the milliseconds drag on the delay becomes perceptible, and then quickly annoying. On a typical PC JACK can get that delay down to the almost imperceptible where a typical non-realtime audio framework struggles to keep it sub-second.

Professional musicians can cope with and compensate for latency up to a certain point. Playing a huge stage, or with some types of instrument that inherently have a latency, you learn. But we're talking low tens of milliseconds at most.

JACK isn't alone here, this a long studied problem. You need buffers, and we have buffers, up to a few thousand frames (samples x channels) which equates to 100+ milliseconds - but beyond that you're just not professional audio any more. And Linux can easily stall non-realtime processes for that long.

If latency didn't matter, there'd be no difference between a realtime NLE and the old batch processed, make a decision and render systems. But in reality the former are tremendously more productive AND require a lot less practice.

[ JACK has a mode for people who don't care about time, freewheel mode, in this mode audio clock time passes as quickly as your CPU can process samples, and of course you don't use RT priority because the machine would appear to freeze indefinitely. ]

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.

Actually you *can* train yourself to do it: I can think of several works in which you have to (the Phase works by Steve Reich, for example). But they're rare, and it's difficult, and you really wouldn't want to do it for everything.