[LAU] A surprisingly stupid RT priority question

Ken Restivo ken at restivo.org
Mon Dec 3 02:27:43 UTC 2012

On Sun, Dec 02, 2012 at 11:03:58PM +0100, Pedro Lopez-Cabanillas wrote:
> On Sunday 02 December 2012 13:00:57 Ken Restivo wrote:
> > 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.
> You are probably talking about sched_setscheduler and friends
> http://goo.gl/kTlOR
> Desktop apps may use RealtimeKit instead of calling that API directly, but 
> Liquidaudio is not this kind of thing, if I've understood it correctly
> http://git.0pointer.de/?p=rtkit.git;a=blob;f=README
> The question is if Liquidsoap really needs low latency audio (small buffers +  
> high/RT priority) or it works better with bigger buffers and high latency so 
> you don't need to worry too much about priorities.

Thanks everyone for the fantastic and detailed answers! Now it is all starting to make sense to me.

Yes, sched_foo were the ones I was thinking of, SCHED_FIFO being the priority for Ingo-ish RT, IIRC.

And yes, it was the requirement for determinsm (no malloc, blocking system calls, etc) that I remember from JACK callbacks, and thanks for confirming that it is a general requirement of RT audio in general, not of JACK in perticular.

Buffering indeed is what sounds like the main issue for Liquidsoap.  But I have no way of knowing how much buffer would actually be necessary to assure it NEVER skips. This is why I was thinking along the lines of some kind of preemption to assure that never happens.

rtkit looks interesting, but if there were a way to this without it, I'd prefer that.

Low latency is NOT required for this application, just stability when starved for resources. Liquidsoap spends almost all of of its time decoding MP3s from disk or reading and decoding MP3 streams off of the internet.


More information about the Linux-audio-user mailing list