When generated visual stimuli, it is possible to get 1 ms reliability. However, effort is required. In the test described here, screen flashes were generated using the Psychophysics Toolbox, and this code. A phototransistor (sample circuit here , change resistor to modify sensitivity) was taped to the screen to convert the light into voltage and was connected to the biosemi analog input box. One LSL events stream was used. The EngineEvents stream generates a marker after every frame flip. If the screen flip is one that also chnages the color from black to white (or vice versa), the EngineEvents stream generates a 'black' or 'white' marker. Otherwise, it generates a 'flip' marker. This allows us to confirm our ability to synchronize the light transitions to the EEG data using the LSL markers as reference. The test was analyzed by loading the data in MoBILAB and running this code, which depends on this function.
Below is an example of the raw data. The red vertical lines are the LSL "white" or "black" events. The green vertical lines are the LSL "flip" events. The horizontal line is the triggering threshold. The blue trace is the feedback from the phototransistor, connected to the biosemi analog input box. The is guaranteed to be synchronized with the biosemi EEG input. A standard known latency of 7.72 ms has been subtracted from the EEG times and 16.13 ms has been added to the marker times.
Below is the latency over time between the raw LSL events and the monitor transitions. There are a fair number of outliers.
These outliers are caused because sometimes there is an extra delay between when the video card flips the screen and when LSL sends the event. This can be corrected for because video card frame rates are very consistent, with one notable exception. The video card will flip every 16.67 ms (assuming a 60 Hz monitor), except that sometimes the frame will not flip at all (and the interval will instead be N times 16.67 ms, where N is an integer). This occurs when the processor does not have time to fill the background graphics buffer before the flip occurs. This somewhat unusual linearization problem is solved by MoBILab, but you have to let it know by including the following block in the engine events stream header:
<desc> <synchronization>
<can_drop_samples>true</can_drop_samples>
</synchronization> </desc>
It is also important to mark an approximately correct graphics card frequency when calling lsl_streaminfo(). Otherwise, the analysis code cannot determine whether or not every other frame is dropped or the frame rate is half of the expected value.
Below are the uncorrected frame intervals, followed by the corrected frame intervals.
You can see that there are sometimes dropped frames. When the code does not have time to fill a buffer with data within the frame interval, the screen flip will get postponed one or more frame intervals. These have to be taken into account, and at the proper time. We can use the corrected screen flip times as a scaffolding to correct the "white" and "black" events, by rounding them to the closest screen flip. This will work as long as the "white" and "black" events are off by no more than half of a frame. Using the corrected frame times, we find the latencies over time, below:
Certain situations can lead to large numbers of dropped frames. In Windows 7, here are a few recommendations:
1) Turn off Aero. Right click the desktop -> Personalize. Click Windows 7 Basic. If Aero is on, it can cause stealth dropped frames, where the software thinks a frame flip occurred, but the phototransistor confirms that is did not. This is problematic as such frames are difficult to correct for.
2) Turn off User Account Control (any time a program activates User Account Control, it pulls focus away from the active application). Start Menu -> Control Panel -> System and Security -> Action Center -> Change User Account Control Settings. Drag the slider down to the bottom.
3) Make sure that the stimulating window is focused, by clicking on it with the mouse after doing something else in any other window.
4) The test described here does not do this, but it is possible to put a phototransistor in the bottom corner of the screen during the experiment, and flip the corner from black to white or white to black every frame. This will allow a verification of timing information during actual experiments rather than just testing. For intensive graphical stimuli with many dropped frames, this is likely a necessity.
5) Run a test where you flip the whole screen from white to black at the maximum rate, while running any calculations you will be doing in the real experiment. This makes it possible to see individual dropped frames by eye. It can also make another common problem trivial to see, in which the video buffer is being written to when the frame flip occurs. In this case, you will see a stitching (also called tearing) error across the screen. This occurs either when the video buffer write is taking too long, or the video buffer write is happening at the wrong time. Video buffer writes tend to happen at the wrong time when you have more than one monitor, because the buffer writes all happen at the same time, while the buffer flips can happen at different times for different monitors. In this case, it is necessary to get a special video card, such as the Quadro K5000, which supports nVidia mosaic technology. It is possible that AMD Eyefinity technology would also perform well, but I have not tested this (though it is significantly cheaper).
The data for this report was taken on 2014/03/03.