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.

Prewarmed DSK keys

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. Prewarming deliberately keeps key subscriptions alive while keys are off. This trades retained frame references for prompt key activation and differs from disabling off-page AUX subscriptions.

Every downstream key stays subscribed while it is off, so a key cut or fade-in starts on the very next program frame instead of waiting 1–2 frames for the browser page’s next paint.

Status: Implemented

The idea

Low latency is the product’s selling point. Scene sources are already prewarmed: their frames flow before a cut needs them. Keys were not. The keyer subscribed to a key’s browser feed only while the key was on. Now it treats keys like scene sources: frames always flow, and the key’s level decides what is drawn.

Before, the command opened the key’s feed, then the keyer waited for the page’s next paint: 1 or 2 program frames of nothing. Now the keyer already holds a frame, so the next program frame can draw it.

Same pattern as scene sources: frames flow whether or not the key is on air. Only the level decides what is drawn.

At a glance

WhatThe keyer enables every key subscription once, the first time it runs, and keeps it. It takes each key’s frames whether the key is on or off and queues up to 6 of them; at each program frame it draws the key’s frame stamped for that tick. It draws only keys whose level is above 0.
WhyBefore, a key subscribed only while on. Turning a key on then waited for the page’s next paint. Every scene source is already prewarmed; keys were the exception.
LatencyKey on, by cut or fade-in: 1–2 program frames → 0 extra frames. It starts on the very next program frame after the command. Program latency: unchanged; the keyer still never waits for a key.
Side effectsNone on the program path. With no key visible the program frame still passes through without GPU work, as before.
Cost0 nodes, 0 queues, 0 threads. The browser already renders these pages all the time; this only delivers frames that were being dropped. Off keys add a queue step per key frame and no GPU work. Memory: an off key now keeps the same frames an on key does, a held frame plus up to 6 queued frames waiting for their program tick. Key frames are small; the largest demo key is 1016×172.
RiskLow. A key switched on shows the page’s paint stamped for that program tick. If the page has not painted since, that frame is older, exactly as for a key already on air.
Switch it offNo runtime switch. Going back means restoring the per-command enable, which brings the 1–2 frame wait back.

Where in the code

src/nodes/mixer_keyer.cpp: processKeyed and the comment that states the rule.
source: every key subscription enabled once (keys_subscribed_, source).
source: every key’s frames are queued, on or off; source the frame stamped for the program tick is taken; the queue bound kKeyQueue is at source.
source: a key is drawn only when it has a frame and its level is above 0; source the pass-through with no key visible.
Docs: config.md · dsk (“Off keys keep receiving frames …”).

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