Re: Estimating JACK latency

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On Wed, May 02, 2012 at 04:51:03PM -1000, Joel Roth wrote:
> On Tue, Apr 17, 2012 at 05:09:52PM +0000, Fons Adriaensen wrote:
> > The nominal roundtrip-delay (physical input to physical output
> > if you connect the corresponding ports directly) is period * nperiods.
> > 
> > 1 * period occurs at the input, (nperiods - 1) * period at the output.
> 
> If this is correct, Patrick Shirkey should update his page at
> 
> http://linux-audio.com/jack/
> 
> Quote:
> 
>     p affects input latency: how long from when a piece of data
>     arrives at the audio interface connectors until user space
>     software can use it?
> 
>     p*n affects output latency: how long from when a piece of
>     data is delivered by user space data until it leaves the
>     audio interface connectors?
> 
>     Roundtrip latency is combination of these two.

Which is not completely wrong, just a little inaccurate.

Suppose you configure for 2 periods. The the following happens:

Capture           A   B   C   D   E   F
Processing        -   A   B   C   D   E 
Playback          -   -   A   B   C   D   

For 3 periods, this becomes:

Capture           A   B   C   D   E   F
Processing        -   A   B   C   D   E 
Playback          -   -   -   A   B   C   

And for 4 periods:

Capture           A   B   C   D   E   F
Processing        -   A   B   C   D   E 
Playback          -   -   -   -   A   B   

The advantage of having more that 2 periods is that processing
can be late without ill consequences, e.g. for 3 periods

Capture           A   B   C   D   E   F
Processing        -   -   A   B   C   D 
Playback          -   -   -   A   B   C   

still works fine. That is, the ALSA API allows this. It's not 100%
clear to me if Jack would allow it, as it has some internal checks
for things being 'on time'.

Jack2's async mode (also the default) adds one period of latency,
things are as if you had configured for one more period. That is
because of doing 

1. Read from capture device
2. Process
3. Write to playback device

in each cycle, it does

1. Read from capture device
2. Write result of previous cycle to playback device
3. Process 


Ciao,

-- 
FA

A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user


[Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

Add to Google Powered by Linux