3 May
2012
3 May
'12
12:15 p.m.
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:
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)
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.