Inconsistent Grab Rates

[dmadison]

Over the past month or so I've been dissecting my custom Adalight setup to try and improve the framerate, and the latest step in that effort was to measure the effect of grab interval on the framerate at various baud rates. And it appears as though the grab interval setting in Prismatik isn't functioning properly.

Here is a graph of the framerate measurements for my 80 LED setup:

The purple line is the ideal framerate produced by a given grab rate. Instead of following the curve, the framerate appears to stay constant and then make several large 'jumps'. In this data there are three clear ones:

1. 48 to 47
2. 32 to 31
3. 20 to 19

The framerate numbers are from measuring the output of the Arduino using a Logic Analyzer. Full details on the methodology here.

I haven't done any tests at other LED counts, larger grab intervals, and I don't know if it's specific to the Adalight implementation - so take this with a grain of salt. But this seems like a rather significant bug.

Do you have any idea what might be causing this?

[psieg]

The grab rate is limited by the configured grab interval (i.e. the purple line). However, with Desktop Duplication, if there are no changes on the screen, no new grab occurs. This might screw with your setup in various ways. Maybe retry with WinAPI capturing which always captures the screen at the specified interval.
I have no real idea how the adalight part of Prismatik works to be honest.

[dmadison]

Just did a short test with the WinAPI and it seems that the framerate, even in the "Grab Frequency" debug, never goes higher than 30 fps. Even at a grab interval of 1 ms.

I ran a quick test with 250000 baud and it seems that the WinAPI is also inconsistent, although the FPS cap makes it less-obvious. Here are the results of the quick test:

Grab Interval (ms)	Framerate
50	~16
47	~21/22
27	~23/24
19	30

I measured intervals from 50 to 1 again, and I've marked the grab intervals where the framerate changes. All of the grab rates between those changes give roughly the same results. The serial data is also inconsistent, sometimes giving a few frames quickly and sometimes pausing before the next. Interestingly at grab rates 19 through 1 the serial data is very evenly spaced, which almost makes me think that the grab timing is derived from 30. But that's pure speculation.

Do you have any way to measure the actual framerate on Lightpack?

[psieg]

The Prismatik window has an FPS counter, which roughly reflects the grab rate. There is currently no tracking of the rate of frames sent to the device, but in theory they should be identical

[dmadison]

Unfortunately I don't have a Lightpack, and Prismatik won't let me change devices without detecting one. If you or someone else could test their framerates with Lightpack we could figure-out if this is a grab issue or a device issue.

With desktop duplication at least I don't think the built-in FPS counter is useful. Because it's an extrapolation the lulls from when a new grab isn't performed cause issues (e.g. while I'm measuring a steady 60 frames per second the Prismatik counter ranges from 2 - 110 FPS). The counter is definitely more consistent with WinAPI, though.

[psieg]

I've rebuilt the FPS counter to be more realistic (Actual counts).
I can kind-of reproduce the behavior you mention (on the capture side, ignoring the baud part).
For now, I assume it is some interaction between the grab interval and the fact that a new frame is grabbed only if new data is available from Desktop Duplication.

It might be Desktop Duplication has an "internal framerate" which is adjusted to "client demand" but can only take a few values for technical reasons

[dmadison]

Yeah the baud is only there for throughput testing. The dropouts are due to saturation of the bus and have nothing to do with Prismatik.

From what I remember when I did the testing last year, I had a video on the screen and I tried to move my mouse around constantly to counteract the 'static frame' issue. So the plateaus at the low capture rates especially strike me as odd.

If it is a desktop duplication limitation with client demand, could you force Prismatik to poll at a faster rate but only parse at the grab rate? That could rule that out as a possibility.

[psieg]

This is what the chart looks like for me (measuring the frame grab rate, ignoring the device).
I'll try to see if I can tweak some things to get it to be smoother, but it might be how Desktop Duplication works internally.