[LAD] Some questions about the Jack callback

[Will J Godfrey]

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.


OK.
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.