[LAU] A surprisingly stupid RT priority question

Harry van Haaren harryhaaren at gmail.com
Sun Dec 2 21:23:36 UTC 2012


On Sun, Dec 2, 2012 at 9:00 PM, Ken Restivo <ken at restivo.org> wrote:

> 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.
>

I'll only try to answer this part of the question:
The audio processing call graph must not do anything indeterministic.
Anything like allocating memory, deallocating memory, grabbing a mutex lock
etc are *all* indeterministic. Any system call unless *explicitly* named
real-time safe, should be considered non-real time. Nice article providing
info on this:
http://www.rossbencina.com/code/real-time-audio-programming-101-time-waits-for-nothing

With JACK clients, JACK registers its audio threads as RT, and then calls
into your code with that thread. You don't have to acquire RT thread
priorities yourself in your program. It is advisable to do a memlock_all()
though, so the memory you're using won't ever be moved to swap.

These steps sound quite easy, but program design and resource creation /
destruction must all be carefully planned in such an environment. If the
program has been designed from the ground up for RT work, no problem. If it
hasn't it could prove difficult to make it RT safe. Buffering is the
nemesis of RT low-latency work: perhaps increasing your buffering will fix
your problems...

Bit of a techie answer, HTH anways. -Harry

PS: Just noticed Paul's said this in one sentence :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-user/attachments/20121202/92661640/attachment.html>


More information about the Linux-audio-user mailing list