Started writing about controlling latency.

diff --git a/hdmisdi.rst b/hdmisdi.rst
index 339e64c582f7232e625056e2af6ce6ad6c56fcc9..2d0d6c4dff55e721b096fa7569a8749707848681 100644 (file)
--- a/hdmisdi.rst
+++ b/hdmisdi.rst
@@ -101,7 +101,24 @@ tradeoffs must be made. The most important sources of latency are:
    The 4K series in this context include everything that have “4K” in their
    names, plus the Mini Recorder, Duo 2 and Quad 2 devices.
 
-TODO: Write about queuing options. And latency measurements. And audio.
+Controlling latency
+...................
+
+Of the different sources of latency outlined in the previous section,
+the only one that is really under your control (short of buying faster
+or better hardware) is the input queue latency. By default, Nageru
+attempts to strike a balance between reducing latency and having to
+drop frames due to jitter; by looking at each queue's input length
+history, it attempts to find a “safe queue limit”, above which it
+can drop frames without risking underrun (which requires duplicating
+frames). However, if latency is more important to you than 100% smooth
+motion, you can override this by using the *--max-input-queue-frames=*
+flag; this is a hard limit on the number of frames that can be kept
+in the queue, on top of Nageru's own heuristics. It cannot be set lower
+than 1, or else all incoming frames would immediately get dropped
+on arrival.
+
+TODO: Write about output queuing options. And latency measurements. And audio.
 
 TODO: Write something about time codes here.