>I'm trying to understand how JACK minimizes the number of context switches >when the clients are out-of-process; if I got this right, this is one of >the cool things it does (if it didn't, we would be able to run only a very >small number of concurrent realtime out-of-process audio apps).
karl answered this earlier, perfectly correctly. note that it wouldn't have a huge effect on system capabilities to swap back to the server each time, but it would definitely be an extra load that we want to minimize. >(since it keeps pointers to these functions). Well, do these process() >functions run inside the server address space (that is, are they part of >the server process, run just like any other server function)? for an out-of-process client, process() runs in the client VM space, but in a dedicated thread. >Getting more practical: suppose one of the nodes is a wave file player; >the "real" application has a thread that reads the disk data. How do this >data get to the process() function, since the process() function shouldn't >block and, therefore, can't read the disk by itself? the rest of the application has to move data to/from a (preferably lock-free) ringbuffer (or similar); the JACK thread created by libjack that executes process() simply pulls data from there. note: there is nothing to stop you from *trying* to do disk i/o in the process() callback, but the JACK server will probably cut you out of the processing chain and/or stop the entire chain if you do, because it will likely lead to timing overruns. --p
