On Sun, 21 Sep 2014 16:51:26 -0400 Paul Davis <p...@linuxaudiosystems.com> wrote:
> On Sun, Sep 21, 2014 at 4:31 PM, Will Godfrey <willgodf...@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. _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev