19 Apr
2015
19 Apr
'15
4:59 a.m.
Hello,
it is often being said that JACK 2 is real time safe, for example in the JACK faq. I
wondered how JACK 2 suspends a thread, so I checked what happens after the JackClient
finished CallProcessCallback():
JackClient::CallProcessCallback()
-> JackClient::CycleWaitAux()
-> JackClient::WaitSync()
-> JackGraphManager::SuspendRefNum()
-> JackConnectionManager::SuspendRefNum()
-> virtual JackSynchro::TimedWait()
However, I found only two classes in the `posix' folder that implement this virtual
function:
* JackPosixSemaphore: uses `sem_timedwait()' to block
* JackFifo: uses `read()' to block
However, both `sem_timedwait()' and `read()' are syscalls, so they contain context
switch, which means they are non realtime. Actually, the JACK documentation warns to use
function like these if you pass a process() callback to jack [1].
So how can JACK claim it would be realtime? (No objections, I just don't understand
it)
Best,
Johannes
[1]
http://jackaudio.org/files/docs/html/group__ClientCallbacks.html#gafb5ec9fb…
19 Apr
19 Apr
7:29 a.m.
On Sun, 2015-04-19 at 11:59 +0200, Johannes Lorenz wrote:
Hello,
it is often being said that JACK 2 is real time safe, for example in
the JACK faq. I wondered how JACK 2 suspends a thread, so I checked
what happens after the JackClient finished CallProcessCallback():
JackClient::CallProcessCallback()
-> JackClient::CycleWaitAux()
-> JackClient::WaitSync()
-> JackGraphManager::SuspendRefNum()
-> JackConnectionManager::SuspendRefNum()
-> virtual JackSynchro::TimedWait()
However, I found only two classes in the `posix' folder that implement
this virtual function:
* JackPosixSemaphore: uses `sem_timedwait()' to block
* JackFifo: uses `read()' to block
However, both `sem_timedwait()' and `read()' are syscalls, so they
contain context switch, which means they are non realtime. Actually,
the JACK documentation warns to use function like these if you pass a
process() callback to jack [1].
So how can JACK claim it would be realtime? (No objections, I just
don't understand it)
The next JACK client in the graph, and the JACK server, run in different
processes from the currently running client (except for internal clients
and multiple clients per process, but those are special cases) so there
has to be a context switch if you want to pass control to them.
It's realtime safe as long as you know that those system calls pass
control to the thread you want them to pass control to and not some
other random thread that has nothing to do with JACK. As long as the
semaphores are posted and waited on in the right order, and the
scheduler is properly configured, and all the threads have the right
priority, it will work. You could in theory pass control to other
threads in your process callback in a realtime safe way if everything
was designed correctly, but there isn't much point in doing so and it's
difficult to get right. Most of the time, for most of the uses, I/O
functions, lock functions etc are not realtime safe.
--ll
8:06 a.m.
There can be no such thing as strict real time safety in a system that
involves task (context switching). JACK does the best possible
approximation given the tools provided by the OS.
You are advised to worry less about the design of JACK internals, which are
now over a decade old and known to work extremely well on supported
platforms, and worry more about your own JACK client code.
On Sun, Apr 19, 2015 at 5:59 AM, Johannes Lorenz <
johannes89(a)mailueberfall.de> wrote:
Hello,
it is often being said that JACK 2 is real time safe, for example in the
JACK faq. I wondered how JACK 2 suspends a thread, so I checked what
happens after the JackClient finished CallProcessCallback():
JackClient::CallProcessCallback()
-> JackClient::CycleWaitAux()
-> JackClient::WaitSync()
-> JackGraphManager::SuspendRefNum()
-> JackConnectionManager::SuspendRefNum()
-> virtual JackSynchro::TimedWait()
However, I found only two classes in the `posix' folder that implement
this virtual function:
* JackPosixSemaphore: uses `sem_timedwait()' to block
* JackFifo: uses `read()' to block
However, both `sem_timedwait()' and `read()' are syscalls, so they contain
context switch, which means they are non realtime. Actually, the JACK
documentation warns to use function like these if you pass a process()
callback to jack [1].
So how can JACK claim it would be realtime? (No objections, I just don't
understand it)
Best,
Johannes
[1]
http://jackaudio.org/files/docs/html/group__ClientCallbacks.html#gafb5ec9fb…
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
3580
days inactive
3580
days old
jackaudio@lists.linuxaudio.org
2 comments
3 participants
participants (3)
-
Johannes Lorenz -
Lars Luthman -
Paul Davis