I hope you are well. I was wondering if I could ask you a question about the behavior of frame display update times in MWorks:
In my MWorks experiment, I have a photodiode looking for a change in luminance of a square on the monitor. If I align the time the stimulus display updates are reported by MWorks (using the timestamp from #StimDisplayUpdate) I see that there is usually a consistent delay between when MWorks predicts the screen to have updated and when it really is (approx 40ms). I think this is expected. The weird thing I’ve been observing is that for discrete periods of time (~100-500 trials) the delay will increase to 60ms, and then after some time will go back to its standard amount. This seems surprising – I would expect the delays to randomly vary with respect to some mean time, but perhaps I am not taking into account how the display update pipeline works on mac. I was also surprised to see this occurring in “blocks,” rather than being evenly distributed through time.
One complication is that to get the time of mworks and the recording system to be aligned with each other, we send matching binary words to the recording system with an ITC-18, then use those timestamps to convert the two running clocks to the same timespace. So the MWorks->USB->ITC->Recording system could be impacting this as well.
My question is this: Is any of what I described unusual? Or does everything sound like it’s all operating at approximately the level of precision I should expect from MWorks display update times?
40ms is actually quite a large delay. With a low-latency display, I would expect the difference between MWorks’ predicted output time and the time measured by the photodiode to be on the order of a few milliseconds (maybe 5ms at most).
Where exactly on the display is the photodiode located? Most displays I’ve worked with update left to right, top to bottom, so the lower right corner of the display will be updated approximately one refresh cycle after the upper left corner. That said, with a 60Hz refresh rate, the refresh period is only ~17ms, so obviously that wouldn’t account for the whole 40ms.
Another possibility is that the display is doing some internal image processing that is adding latency. I usually recommend that folks use displays developed for gaming (or activate their display’s “gaming mode”, if it has one) in order to minimize such internal latency.
One complication is that to get the time of mworks and the recording system to be aligned with each other, we send matching binary words to the recording system with an ITC-18, then use those timestamps to convert the two running clocks to the same timespace. So the MWorks->USB->ITC->Recording system could be impacting this as well.
Yeah, that could be part of the issue, both in terms of the high overall latency and the variability. Have you tried connecting the photodiode to an analog input on the ITC, and then reading both MWorks’ predicted display update time and the photodiode time from the MWorks event file? That would at least take the recording system and associated timestamp alignment out of the loop.
It might also be worthwhile to do a similar test with another I/O device. If you have an Arduino board handy, you could set it up as a Firmata device and feed the photodiode signal in to it (and thence to the event file). That would let you rule out any latency being added by the ITC-18.