[LAD] Some questions about the Jack callback

Will J Godfrey WillGodfrey at musically.me.uk
Sun Sep 21 22:10:33 UTC 2014

On Sun, 21 Sep 2014 16:51:26 -0400
Paul Davis <paul at linuxaudiosystems.com> wrote:

> On Sun, Sep 21, 2014 at 4:31 PM, Will Godfrey <willgodfrey at musically.me.uk>
> wrote:
> > ually...
> >
> > This might seem a bit obvious, but am I right in thinking that while jack
> > collects the current inputs it is at the same time pushing out the
> > *previous*
> > bufferful of data - hence latency.
> >
> you're wrong. sort of.
> the simplest way to think about this is with the double buffered model that
> ASIO enforces, which in ALSA is equivalent to 2 periods.
> while the audio interface is (playing|capturing) one buffer/period, JACK is
> (collecting|delivering) data for the other. when the audio interface is
> finished, we flip so that the h/w is now working with the buffer/period's
> worth data that JACK just finished with (i.e. either playing it or
> refilling the capture part), and meanwhile JACK is again
> (collecting|delivering) data to its clients. and on and on it goes.
> thus, if JACK is not done (collecting|delivering) data by the time the
> audio interface is ready to flip ... xrun.
> the latency comes from the fact that in a block-structured handling model
> like this, the output played by the audio interface can under NO
> circumstances ever be based on anything earlier than the previous
> buffer/period. audio data that arrives at the audio interface will get
> delivered to JACK at some point in the future, JACK clients will do
> something with it (e.g. playing it back as-is) and then 1 buffer/period
> after it became available to JACK (and its clients), it is available to the
> audio interface to playback again.

Got that. Thanks for the explanation.

It wasn't me! (Well actually, it probably was)

... the hard part is not dodging what life throws at you,
but trying to catch the good bits.

More information about the Linux-audio-dev mailing list