2 Dec
2012
2 Dec
'12
10:23 p.m.
On Sun, Dec 2, 2012 at 9:00 PM, Ken Restivo <ken(a)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-…
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 :)