<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Sep 21, 2014 at 4:31 PM, Will Godfrey <span dir="ltr"><<a href="mailto:willgodfrey@musically.me.uk" target="_blank">willgodfrey@musically.me.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">ually...<br>
<br>
This might seem a bit obvious, but am I right in thinking that while jack<br>
collects the current inputs it is at the same time pushing out the *previous*<br>
bufferful of data - hence latency.<br></blockquote><div><br></div><div>you're wrong. sort of.<br><br></div><div>the simplest way to think about this is with the double buffered model that ASIO enforces, which in ALSA is equivalent to 2 periods.<br><br></div><div>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.<br><br>thus, if JACK is not done (collecting|delivering) data by the time the audio interface is ready to flip ... xrun.<br><br></div><div>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. <br></div></div></div></div>