[LAU] A surprisingly stupid RT priority question
ken at restivo.org
Sun Dec 2 21:00:57 UTC 2012
OK, I know I've been using Linux audio for 6 years now, and gigged and recorded with it extensively for most of those, yadda yadda. But it seems I've had an embarassingly huge hole in my knowledge the whole time.
I was under the impression that, in order to use real time priorities/permissions and Ingo kernels, it was required for the process ITSELF early in the main() routine of its source code, to make some system calls to claim RT priority. In fact, I specifically remember reading or even writing source code in C which did that (probably based on JACK sample code). I don't recall the name of the syscall, but it was something obvious and well-documented.
Also, I remember that it was also required that the software behave properly in order to be real-time capable, something about callbacks taking some predictable amount of time. Or perhaps that was only a JACK requirement.
Why am I asking these dumb-ass questions now? Because I've been playing around with Liquidsoap and Airtime for some radio stations, and I'm obsessed with getting them as rock-solid on cheap/free/old hardware as I'd been able to get with my gigging and studio synths.
It physically pains me to hear audio stuttering because Apache is running on the same box. It seems an outrage to me. Shouldn't happen. Ever. I used to record and mix multi-track songs in Ardour with tons of soft-synths WHILE A KERNEL COMPILE WAS GOING ON THE SAME MACHINE without a single glitch. I expect no less.
So I asked on the Liquidsoap list, and I got only shrugs and a pointer to the Gentoo page in response (why? I have no idea. I use Debian, and that's irrelevant to the question at hand anyway.).
So what's the deal? Is there a way to give Ingo-approved preemptive RT priority to things that aren't real-time apps and aren't specifically architected for that? What, if anything, would break?
And, if I wanted to hack Liquidsoap (which would require learning ML, which wouldn't be a bad thing to know anyway), is it even possible to get it RT-capable, or are there low-level C system calls required in order to make that work?
Sorry for the long and obscure question, but it's been bothering me for a while, and I figured someone here would know the answer, or where I might find it.
More information about the Linux-audio-user