19 Apr
2015
19 Apr
'15
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