v0.2.9 - Resolve knows how much latency your plugins have

Resolve now knows how much latency your plugins have, and compensates for it.

Stacking effects used to push the audio out of sync with the video, and the first moments after a
jump in the timeline replayed the end of the previous position. Both are fixed, and both are
confirmed on the machine that reported them.

The bug, in one line

GetPluginLatency -> 0    plugin says 6144

Resolve asks each effect how much latency it has, once, at project load. The plugin knew — 6144
samples, 2048, 1080, 720. The bridge answered zero every time, so Resolve compensated for none
of it, and the error grew with every effect you stacked.

It now answers with the plugin's real figure. Only the answer is ours: the poll, the cache, the
mutex and Resolve's own delay compensation are untouched. That machinery was working correctly the
whole time, on an input of zero.

Confirmed from both directions — correct sync with the audio track back at zero offset, and the
cached value Resolve actually reads now carrying 1024, 6144, 2048, 720 and 1080 where every earlier
log showed zero.

And the jump

Resolve tells an effect when the playhead moves, a dozen times a session. The bridge dropped it, so
delay lines, lookahead buffers and reverb tails survived a locate — the first moments after a jump
were the tail of wherever you had been.

The plugin is now told: VST3 setProcessing off and on, VST2 stop and start process, CLAP
reset(). It happens at the top of the next audio block rather than the moment Resolve announces
it, so it can never land inside processing on another thread.

Known, and not fixed

• A short silence when playback starts with a high-latency plugin loaded — a few hundred
  milliseconds. Exports are not affected; the rendered file is correct. It is not the reset:
  turning that off with FXBRIDGE_RESET=0 leaves the gap exactly as it was. Still being chased.
• A plugin that changes its latency while the project is open may not be re-compensated until
  the project is reopened.
• One instance in one session reported 768 samples to the plugin and zero to the cache, where every
  other instance agreed. Undiagnosed, 16 ms.

Install

curl -L -o ~/.local/share/BMDAudioPlugins/libfxbridge.so \
  https://github.com/JaySNL/VSTForResolveLinux/releases/latest/download/libfxbridge.so
curl -L -o ~/.local/share/BMDAudioPlugins/fxbridge-scan \
  https://github.com/JaySNL/VSTForResolveLinux/releases/latest/download/fxbridge-scan
chmod +x ~/.local/share/BMDAudioPlugins/fxbridge-scan

Your cache and deny list are kept. The log names each effect's latency:

[fxbridge] latency: "Acon Digital DeVerberate 3" reports 6144 samples

FXBRIDGE_LATENCY=0 and FXBRIDGE_RESET=0 turn the two halves off. They exist for narrowing down
a problem, not for daily use.

How this was found

Two instrumented builds that changed nothing and only wrote down what Resolve asked, before a line
of the fix was written. That is also how the first plan was caught being wrong: Resolve calls the
thunk entries, not the ones the analysis named, and a fix aimed where it was planned would have
changed nothing and looked like a dead theory.

The whole account, wrong turns included, is in
docs/latency-and-reset.md.

The binaries

Built from the v0.2.9 tag in an Ubuntu 20.04 sandbox, so they run on Ubuntu 20.04, Debian 11 and
Rocky 8. libfxbridge.so floors at GLIBC_2.16.

ab4936f505d50704a36c7da45608ecd031fcc1d74762bd59595794060c42afe9  libfxbridge.so
fcfcbb900031198219887721a3c40eee2cd01ae75b7d0215eceb1d5b3ac4ff90  fxbridge-scan