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@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#gafb5ec9fb4b736606d676c135fb97888b
_______________________________________________
Jack-Devel mailing list
Jack-Devel@lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org