Subject: Re: [linux-audio-dev] Simple question on JACK and callbacks
From: Paul Davis (pbd_AT_Op.Net)
Date: Thu Nov 15 2001 - 00:19:10 EET
>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
This archive was generated by hypermail 2b28 : Thu Nov 15 2001 - 00:18:23 EET