Re: [LAU] A surprisingly stupid RT priority question

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Ken Restivo <ken@...>
Cc: <linux-audio-user@...>
Date: Sunday, December 2, 2012 - 9:23 pm

--e89a8ff1c2e8e9637b04cfe53ebc
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Dec 2, 2012 at 9:00 PM, Ken Restivo wrote:

> Also, I remember that it was also required that the software behave

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

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 :)

--e89a8ff1c2e8e9637b04cfe53ebc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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

Also, I remember that it was also required that the software behave properl=
y in order to be real-time capable, something about callbacks taking some p=
redictable 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 r=
eal-time safe, should be considered non-real time. Nice article providing i=
nfo on this: http://www.rossbencina.com/code/real-t=
ime-audio-programming-101-time-waits-for-nothing

With JACK clients, JACK registers its audio threads as RT, and then ca=
lls into your code with that thread. You don't have to acquire RT threa=
d 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 n=
emesis of RT low-latency work: perhaps increasing your buffering will fix y=
our problems...
Bit of a techie answer, HTH anways. -HarryPS: Just noticed Paul=
's said this in one sentence :)

--e89a8ff1c2e8e9637b04cfe53ebc--

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[LAU] A surprisingly stupid RT priority question, Ken Restivo, (Sun Dec 2, 9:01 pm)
Re: [LAU] A surprisingly stupid RT priority question, Paul Coccoli, (Sat Dec 8, 7:20 pm)
Re: [LAU] A surprisingly stupid RT priority question, Pedro Lopez-Cabanillas, (Sun Dec 2, 10:04 pm)
Re: [LAU] A surprisingly stupid RT priority question, Ken Restivo, (Mon Dec 3, 2:27 am)
Re: [LAU] A surprisingly stupid RT priority question, Aaron Krister Johnson, (Mon Dec 3, 4:48 pm)
Re: [LAU] A surprisingly stupid RT priority question, Harry van Haaren, (Sun Dec 2, 9:23 pm)