[Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15

[Paul Davis]

>Paul Davis wrote:
>
>> JACK is specifically designed not to allow latency jitter. you can't
>> properly sync audio+video with latency jitter, because the software
>> cannot know for sure when the audio it generates will actually become
>> audible.
>
>Why not ? 
>
>If B = buffer size, Fs = sample frequency, T = start time, and the
>buffer if pre-filled before starting, then the k-th sample will reach

the buffer may have been prefilled. but the problem arises when you've
missed some period deadlines. you no longer have a full buffer and you
don't know how much of the buffer you are filling if you do it 1
period at a time. if you ask how much total space is available, then
that will work, but this then requires dynamic buffer resizing inside
the software, or alternatively, the software has to use buffers sized
to hold the entire hardware buffer, which is very wasteful.

using the process-in-period-sized-blocks model, if you missed several
period deadlines, then the "last" audio you deliver as you finish
catching up has longer latency than the ones you processed at the
beginning.

this is why JACK uses ASIO's model of 2 periods per buffer by default,
and under RT operation it doesn't allow you to miss any deadlines.

--p