Historical recipe — not current setup guidance. Measurements and implementation links below belong to their original workload and revision. Deployment labels and defaults may be obsolete. Use the reviewed performance recipes; browse historical evidence.

PGM delay instead of a longer aux deadline

Implementation links are pinned to develop at c20464a5 (2026-10-09); read against develop at 8fa15c92 on 2026-10-13 and still current. Measurements retain their original workload and scope. Watch the current 192-input L4 demo.

Current scope. The 80 ms diagram is specifically the 25 fps example. Canvas latency defaults depend on frame rate; program-pad delay depends on AUX rate. Source pads do not inherit the program pad offset.

The Program preview aux keeps the normal 80 ms deadline for all its sources and shows only its PGM pad one frame back, because the finished program arrives a frame later than the sources it is made of.

Status: Implemented

The timing

Every compositor draws output time T at T + 80 ms (a 2-frame playout deadline at 25 fps). An input that misses the deadline repeats its last frame; nothing stalls. The Program preview aux (layout pgm_pvw_grid: 100 source pads + 1 PGM pad) also takes the finished program. That leaves the M/E at about T + 2 frames + keyer ≈ T + 96 ms, after the deadline.

Red bars are the M/E making the program; hatching is time an input waits in the aux queue before the amber draw. The ~T+96 ms program arrival is an approximate figure (2 frames + keyer); the ~T+56 ms is the same delay one tick earlier.

Layout pgm_pvw_grid: 100 source pads plus one PGM pad. The PGM pad is the last input, and only it is shifted.

At a glance

WhatOne integer bus field, pgm_delay_frames (default 1, 2 at a 50/60 fps bus), passed to the Program preview compositor aux_mv_comp. It applies to the last input only, the program feed aux_mv_pgm: output tick T takes PGM T−1. The other 100 inputs keep the normal 2 frames.
WhyThe old fix raised the whole aux to 120 ms (3 frames). Measured live: aux_mv_comp latency_ms = 120, aux_mv2_comp = 80, M/E at the default 2 frames. All 101 inputs waited a frame to help one.
Latency
Program output: unchanged. This is a monitor.
Program preview aux: source and PVW tiles 120 → 80 ms (−1 frame, −40 ms). PGM tile: 120 ms, unchanged.
Command-to-screen on this monitor: a cut reaches the PGM tile as before; changes on the other tiles show one frame (40 ms) sooner, because tick T is drawn at T + 80 instead of T + 120 (derived from the deadline, not measured).
Side effectsThe PGM tile shows one tick older than the tiles beside it, so PVW and PGM are no longer the same instant. The aux now has the same deadline as every other compositor. The Source pages layout does not use the parameter.
Cost0 nodes, 0 queues, 0 threads, about 20 lines. The offset moves a queue slot index; no extra draw work. VRAM: frees the extra frame that all 101 inputs held, ~105 MB (up to 216 MB).
RiskThe program keeps the old margin: PGM T must arrive by T + 120 ms, as before. If it is late, the PGM tile repeats its last frame; nothing stalls. Latency plus offset must fit the six-frame history budget (240 ms at 25 fps), so the aux accepts 40 ms less main latency. The parameter is rejected on a compositor driven by clock_input.
Switch it offSet the bus's pgm_delay_frames to 0 and its latency_ms one frame higher (120 at 25 fps).

Where in the code

src/nodes/mixer_compositor.cpp: reads pgm_delay_frames and applies it to the last input; mixer_keyer, which has no playout, takes none.
src/mixer/Playout.hpp: Playout::setInputOffset and its six-frame budget check; source shifts the input's slot.
pyplumber/mixer/aux.py: the bus field pgm_delay_frames, default 1 (2 at a 50/60 fps bus, default_pgm_delay_frames); source check the budget in Python; source passes it to the node when it is not 0.
Tests: tests/mixer/test_aux.py, tests/mixer/test_backend.py.
Docs: config.md · aux_buses (the paragraph on the PGM tile running one aux frame behind).

Source links identify the reviewed code, independently of deployment state.