On Sun, Dec 2, 2012 at 9:00 PM, Ken Restivo <ken@xxxxxxxxxxx> wrote:
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 :)
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 :)
_______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
