Hi Martin - after uninstalling a ton of software, replacing all my network hardware, and pulling a few hundred feet of CAT 2 out of my walls, I accidently stumbled on the trigger. It was about the last thing I expected, and while I can't explain the 'why' part, it's pretty interesting.
Two servers:
(1) 'Mixer' has just vMix all alone, with just ffmpeg encoding, cameras, and a Flash 'SWF' overlay input that does custom graphics (titles, crawl, sponsors, etc), and,
(2) 'Controller', which has a dotNet thick-client UI for selecting races, switching cameras, etc, as well as an IIS web server accessed by the SWF.
'Controller' polls and automates vMix via the API, and 'Mixer' similarly reaches back via the SWF to the IIS website on Controller to keep the graphics up to date. Basically, each machine runs both a web server (vMix & IIS) and a web client (SWF & thick-client UI), so there's a lot of http traffic going both ways.
The trigger seems to be Flash - the presence of the Flash SWF as an input somehow affects the speed of the vMix web server, i.e. a consistent 1 or 2 ms per call vs 200 ms per call, with nothing in-between.
You may now be thinking 'Ah, badly written Flash code hogs and blocks and slows it all down - case closed'. But wait - it's actually the reverse - the vMix web server speeds up when the Flash input is open! I open the Flash input and immediately the vMix API latency drops to insanely fast. Close the Flash input, and that very instant it jumps back up to 200 ms.
There's more... I'd think, 'OK, because of all that back and forth traffic, some network setting between the two machines gets cached or something, so dotNet gets smarter about the http logic, and skips whatever dumb@ss step takes 200 ms'. In that case, Controller would see the benefit, but another separate / third machine would remain slow since it's not part of the Flash conversation. Nope - yet another surprise - when I ran the Controller UI on an otherwise virgin machine it sped and slowed just like Controller. Basically, the benefit Flash gives applies to all clients of the vMix web server.
I'm pretty sure about all the above. In particular I've been sure to test the vMix status output under the insanely fast case to see that old results aren't being cached, but I can clearly see the video position value blurring away faster than I can read. At this point all this is more FYI than support query - even at 200 ms the UI would be usable, though I like it much better at <2 ms ;)
Still unknown - is it just the Flash libraries being loaded that makes the difference, or is it the network traffic my code creates? I may look at that in a couple of weeks when things slow down.
Thanks!
David
