>How would this system scale to a system with multiple processors? Can >it scale? > >If I understand this correctly, this system is doing a form of >cooperative multitasking... with the Jack server making sure >everything is going OK. But, it seems that only one of these >audio processes is running at a time. And thus, you would be >taking advantage of a multiprocessor system. (Or am I missing >something?)
no, you're not missing anything. its entirely an internal implementation detail of any given JACK server how it does this stuff. the API says *nothing* about it. or then again, maybe you are ... lets get a couple of things straight: this system is not useful for operation over a network, because its goals are *low latency*. round trips to adjacent machines don't fit into that scheme. so we're talking only about SMP machines, not clusters. there are other systems for network audio; none of the one's i've read about do low latency well, if at all. now, when it comes to SMP machines, for 99.9% of interested parties, we're talking about dual processors. on such machines, its highly advantageous to leave one processor free for a UI work. and i do mean *highly* advantageous :) of course, i'm a known fan of "chromed" GUIs, so thats just MHO. next, we're talking audio data here for the most part, in which parallel computation is only possible to the extent that there are completely independent sub-streams - the temporal dependence of later data on earlier data prohibits the kind of parallelization you can do in, say, N-body problems. as a result of these observations, i decided in my trial implementation of the API to avoid the potentially large complexities of running multiple audio threads. all clients are run in a single series chain. i know that gstreamer (and perhaps GLAME too) appear to have worked these issues out. if so, thats great, and i hope that their designs can be incorporated into jackd at some point, so that (1) if there are independent substreams and (2) there are more than 2 processors then it could support multiple audio threads. there are some vague ideas present in the existing code base that point in this direction. but please remember: this is completely invisible from an API perspective: clients provide their callbacks, their callbacks get run at the right time, and thats it. --p
