AVPlumber · Mixer cookbook

1. Give independent CUDA streams enough work queues

The L4 stack uses 32 compute connections and eight copy connections. This is driver scheduling, independent of the browser frame queue of nine.

Reviewed 15 October 2026 against e72ff8b4. These pages describe that code and named workload settings; they do not assert what every deployment runs.

What changes

CUDA streams express ordering within a sequence of GPU work. The driver maps them onto a smaller set of work queues. Independent streams sharing a queue can acquire false dependencies and serialize. Raising the queue count reduces that risk; it does not add execution engines or guarantee simultaneous execution. NVIDIA documents the default as eight, with a range of 1–32. CUDA environment-variable reference.

CUDA_DEVICE_MAX_CONNECTIONS=32
CUDA_DEVICE_MAX_COPY_CONNECTIONS=8

The second variable explicitly keeps copy connections at eight; otherwise the first affects both. Set them before the mixer creates its CUDA context and restart the mixer. They are defaults in the L4 Compose override, not universal CUDA or mixer-library defaults. No Chromium rebuild is required.

Keep stream ownership and dependencies explicit

Browser imports queue no GPU work: the compositor samples the mapped buffer. AUX buses have their own streams on the shared CUDA context; raw uploaders use private streams. Consumers must wait for producer work before sampling a frame. A nonblocking stream avoids implicit legacy-default-stream ordering; it does not mean a host thread never waits.

The old “one main stream for almost everything” explanation is no longer a useful tuning rule. More queues help expose independent work, while all streams still compete for the same hardware. Increasing queues cannot repair an overloaded encoder or a compositor doing too much work.

Evidence and scope

In the investigation's 36-browser, 50 fps comparison, on the since-removed fenced browser build, average browser acquire-fence waits fell from about 14 ms to 1.7 ms, and the short transition test went from thousands of source repeats to none. Reduced serialization is the likely explanation; the exact dependency chain was not traced. These diagnostic readings do not establish a general speedup factor.

The committed capacity note records the later 40-window/50-fps result with four workers, the since-removed fixed pool nine with a copy on import, and 32-layer transitions. Both worker grouping and queue settings belong to that configuration. At 60 fps the demonstrated limit remained 30 windows with cheaper AUX encoding. See the full scope and counter results.

Check a change

Compare the same show, rate, output presets and transition sequence after warm-up. Record on-air source repeats/skips, import churn, draw times and output cadence alongside CPU/GPU utilization. A lower CPU number is not a win if source delivery collapses. Override the environment values and restart for a controlled comparison.

Implementation at the reviewed revision