Subject: Re: [linux-audio-dev] Simple question on JACK and callbacks
From: Andy Wingo (apwingo_AT_eos.ncsu.edu)
Date: Wed Nov 14 2001 - 17:49:39 EET
Hi Nelson,
> At each tick, JACK "calls back" on the process() functions of all the
> registered nodes, right? That is, it "jumps" to each of those functions
> (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)? If so, how
> do they do their work (that is, how do they access the data they need)?
> And, if so, shouldn't this be called "in-process"?
Well, as far as I've been able to undersand, the implementation of jack
goes like this:
you have two things, the jack server (call it jackd) and the jack lib
that your app links to (call it libjack)
when you start your app, libjack looks for a running jackd. if jackd is
not running it quits. so you need to have run jackd ;)
then, one shm segment and two pipes are set up between libjack and
jackd. the shm segment is for the audio data. the first pipe is for
'events' (like graph reordering). the second is to notify that data is
ready. when you do jack_run (or whatever that function's called, i don't
recall myself) it sets up a thread that polls on those two fd's. if data
is read the callback is called, with a straight-up function call. so no
jumps are used in that sense.
> 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?
You need to have grabbed it already in another thread.
> OTOH, if the process() function is not run inside the server, but as a
> thread of the "main" app, how does this save any context switches?
One other thing I forgot to mention is that the shm memory is only valid
after you receive the 'data ready' signal (i.e., after you can read from
the second fd). Then, once you're done with it, you write on the same fd
to tell the server you're done.
This is all very implementation-side, so most app writers should not have
to worry about this. but to summarize, process() gets called between
libjack wakes you up from the poll() and before libjack writes on that
fd.
now, how this reduces context switches, I don't really know ;) could be
something about how poll is implemented, i'll admit my ignorance on this
one.
cheers,
wingo.
This archive was generated by hypermail 2b28 : Wed Nov 14 2001 - 17:52:33 EET