Some emails about latency

From FreeBoB

Email 1 (May 10, 2005)

> I've heard a few times about a bug adding latency. It was for instance
> mentioned on LAC. Is this perhaps a fix for this or does the problem still
> exist?
>
This (nb: prealpha2) should be the fix for one of the latency sources. Basically what
happened was that when a transmit underrun occured the non-processed
received samples remained in the ringbuffer. This accumulated over time.
And jackd does have the tendency to underrun when connections are
made/broken (cfr the talk about jackdmp at lac2005).

Now the sync between incoming and outgoing streams is kept, and buffers
are flushed upon underrun.

But some other latency sources exist. I think this version goes down to
20 to 40ms roundtrip delay but I havent actually measured it becaus my
scope isn't available for the moment. I'll take a look at it later.

Email 2 ()

Apparently the -b parameter does have significant effect on latency.
I find this rather strange, but anyway, i'll dig into this.

using the recently (today) announced qjacklam latency meter (see jackit-devel 
or linux-audio-devel mailing lists) I achieve a roundtrip latency of 535 frames 
with these  settings:

  jackd -R -d iec61883 -o osc.udp://localhost:31000 -p 64 -i 10 -s 4 -t 4 -b 40

This corresponds to about 11ms roundtrip latency. This is measured by attaching 
a cable between an input and output port of the device and then measuring the 
time a signal takes to pass through (in frames).

the following settings also worked:

453frames/9.4ms with jackd -R -d iec61883 -o osc.udp://localhost:31000 -p 64 -i 5 -s 4 -t 4 -b 25
421frames/8.8ms with jackd -R -d iec61883 -o osc.udp://localhost:31000 -p 32 -i 5 -s 0 -t 4 -b 25

I am pretty happy with this kind of performance. CPU usage is rather high atm, but that can be solved.
The roundtrip latency I measured for the ASIO driver at its lowest latency setting ("2ms") 
was 12ms. So I would say the latency performance between both is similar.

There are some pitfalls though: first of all, there is a bug somewhere that causes packet loss 
from a certain time on. The driver starts correctly, and during the first minutes all is ok,
but then it starts dropping packets. So were not quite there yet, but it is promising.

I would think running with these parameters is safe if you have a RT capable kernel 
(I run 2.6.11.6 with realtime-lsm).

jackd -R -d iec61883 -o osc.udp://localhost:31000 -p 128 -i 10 -s 8 -t 8 -b 50

which gives about 14ms roundtrip latency.

Greets,

Pieter

BTW:
 ->     2689k Packets, Bufferfill (I:   32, O:    0), Packets dropped (I: 34172, O:   12), XRUNS (   0)
I=incoming, O=outgoing
the "Packets dropped" values are reported by the IEEE1394/RAW1394 kernel space drivers.
the XRUNS parameter indicates how many times jackd couldn't provide the needed frames in time.