Sync failure on a dual display setup

Bugs & Features
1

Hi Psychtoolbox Forum,

I am trying to run PTB on a dual-display setup where the display1 shows the visual stimuli and the other display2 shows the desktop (with simultaneous EEG recording and Matlab interface). Both displays have the same resolution. The problem is that PTB seems to run well in terms of proper VBL synchronization without EEG recording software on (on display2).

Below are the information and warnings.

Psychtoolbox Version: 3.0.15

Matlab version: Matlab 64-Bit (Version 3.0.15 - Build date: Jul 18 2019).

Platform: Windows 10 (Version 10.0) supported and tested to some limited degree.

PTB-INFO: The detected endline of the vertical blank interval is equal or lower than the startline. This indicates

PTB-INFO: that i couldn’t detect the duration of the vertical blank interval and won’t be able to correct timestamps

PTB-INFO: for it. This will introduce a very small and constant offset (typically << 1 msec). Read ‘help BeampositionQueries’

PTB-INFO: for how to correct this, should you really require that last few microseconds of precision.

PTB-INFO: Btw. this can also mean that your systems beamposition queries are slightly broken. It may help timing precision to

PTB-INFO: enable the beamposition workaround, as explained in ‘help ConserveVRAMSettings’, section ‘kPsychUseBeampositionQueryWorkaround’.

PTB-INFO: OpenGL-Renderer is NVIDIA Corporation :: GeForce GT 710/PCIe/SSE2 :: 4.6.0 NVIDIA 461.09

PTB-INFO: VBL startline = 1050 , VBL Endline = 1049

PTB-INFO: Measured monitor refresh interval from beamposition = 16.697044 ms [59.890841 Hz].

PTB-INFO: Will use beamposition query for accurate Flip time stamping.

PTB-INFO: Measured monitor refresh interval from VBLsync = 16.698216 ms [59.886637 Hz]. (50 valid samples taken, stddev=0.846590 ms.)

PTB-INFO: Reported monitor refresh interval from operating system = 16.666667 ms [60.000000 Hz].

PTB-INFO: Small deviations between reported values are normal and no reason to worry.

PTB-INFO: ==============================================================================================================================

PTB-INFO: WINDOWS DWM DESKTOP COMPOSITOR IS ACTIVE. On this Windows-10 or later system, Psychtoolbox can no longer reliably detect if

PTB-INFO: this will cause trouble for timing and integrity of visual stimuli or not. You might be just fine, or you could be in trouble.

PTB-INFO: Use external measurement equipment and independent procedures to verify reliability of timing if you care about proper timing.

PTB-INFO: ==============================================================================================================================

WARNING: Couldn’t compute a reliable estimate of monitor refresh interval! Trouble with VBL syncing?!?

----- ! PTB - ERROR: SYNCHRONIZATION FAILURE ! ----

One or more internal checks (see Warnings above) indicate that synchronization of Psychtoolbox to the vertical retrace (VBL) is not working on your setup. This will seriously impair proper stimulus presentation and stimulus presentation timing!

Please read ‘help SyncTrouble’ for information about how to solve or work-around the problem. You can force Psychtoolbox to continue, despite the severe problems, by adding the command. Screen(‘Preference’, ‘SkipSyncTests’, 1); at the top of your script, if you really know what you are doing.

Below are the errors I got:

Error using Screen

See error message printed above.

Error in PsychImaging (line 2104)

[win, winRect] = Screen(‘OpenWindow’, screenid, clearcolor, winRect, pixelSize, numbuffers, stereomode, multiSample, imagingMode, specialFlags, clientRect, fbOverrideRect);

Error in SRT_task_modified_timgingtest (line 95)

[window, windowRect] = PsychImaging(‘OpenWindow’, screenNumber, black, [], [],[],[]);

After reading the ‘SyncTrouble’. I assume the problem may be out of this dual display setup that the graphics card failed to sync to the display2. I tried several tips from the ‘SyncTrouble’:

  • turned off the EEG recording software on display2, the PTB ran well, without error reports. (But the EEG recording is required during the visual stimuli)
  • minimized the EEG recording software on display2, didn’t help. But the interesting thing is, having an online video on and minimized the website at the same time didn’t clash with the PTB. It seems that the recording software breaks the timing, maybe because it consumes too much CPU load?
  • assign the display1 (where the visual stimuli present) as the primary display, still crashed.
  • set two displays with different and same refresh rate, didn’t help.
  • another issue comes to me when I was testing (although I should have noticed earlier). Because of the port connections, my original display is identified as display2 (where the desktop and EEG recording software lie), and the external monitor for visual stimuli is display1. The codes for call the Screen() function is screenNumber = max(Screen(‘Screens’)); Screen(‘Screens’) returns variables 0,1,2. According to the codes, I actually called the display2 to show the stimuli, but why, instead, the visual stimuli is present on display1?

I learned that it is probably not because of the PTB bug, but right now, as a rookie, I have no idea if there are any other solutions I could try. Any advice and suggestions will be appreciated.

Best regards,

Yufei

1 Like
2

In general, unless you are very lucky, you will not get reliable timing on a dual monitor setup on Windows 10, whether PTB is able to detect this or not. It may be best to run the EEG software on a separate system. Or is Linux an option?

Note also that your PTB is rather old. Consider upgrading to the newest version and trying again.

2 Likes
3

Hi Diederick,

Thanks a lot for your prompt reply and suggestions. Linux would be great but right now I couldn’t do too many changes as one colleague is running his experiment with this existing experimental setup. Having the EEG recording and PTB running separately seems to be the optimal solution. I will try to run the PTB with my laptop and hope it could work.

4

@Yufei
Well, I was also facing difficulties to understand Linus but your post helped me to know about it as much as possible. :slightly_smiling_face:

5

Hello, I hope my question helped @ [hamblingreg52 (Profile - hamblingreg52 - Psychtoolbox).
With our existing setup, I am considering using a Photodiode recording with EEG amplifier to obtain the timing of stimuli onset. Just have another question here and it would be nice to have your or any other’s advice.
From my understanding, this way would be more precise than TTL digital triggers as there are always time lags caused by the luminance response of the monitor. Correct? So if this is the case, the Photodiode alone would solve the problem and work as the ‘ground truth’, why would one bother optimizing the timing efficiency via the hardware or anything else?

6

This “ground truth” depends on where on the screen you place your photodiode relative to where the stimulus is, as there is still a difference in time in the order of milliseconds dependent on your screen type. In addition there are differences in time base on the luminance-to-luminance transition, so if you use a white square for the photodiode it may give a slightly different time course than an e.g. grating. If your study is claiming a latency difference of a few milliseconds between brain areas for example, these differences must still be taken into account.

But yes, in general, even if you have a professional vision display like a VPixx or Display++ (where triggers are synced precisely to display onset), a photodiode is always a good thing to have in a setup.

Alongside a photodiode, I always send a digital trigger too, because one can send strobed words so that the recording system has a precise numerical record of the stimulus and any behavioural responses. Strobed words can make data analysis more straight-forward and add redundancy in the data which is always good. Good timing and repeatable latencies for the strobed words help.

But “good timing” is also important for stimulus fidelity. If your Windows system is dropping frames, then animations may jump, and this causes non-linear transitions that will affect your data. Most windows systems I’ve seen people just turn off the timing tests, so they cannot know if and how many frames are being dropped. Linux is just more reliable, with less timing glitches and less dropped frames on the same hardware. Especially if you do neurophysiology, you should be trying to ensure reliable and repeatable stimuli as visual neurons can be driven by such artifacts.

1 Like
7

Let me just strongly concur with the statement that data redundancy is a good thing. Logging more, and in multiple ways is a good thing. Things that you may think are redundant may turn out not to be due to bugs in your code, someone else’s code, hardware setup or the hardware itself–or wrong assumptions/mental working models for that matter. Exploiting redundancy by analyzing the various sources separately and seeing if they match is a little extra work, but goes a long way to uncovering subtle problems. This improves the quality of your science (and will reduce the change for a retraction later!)

1 Like
8

I really appreciate your explanations, it is extremely helpful as I was struggling to understand the logic behind it.

9

Thanks a lot for your valuble suggestions. I will also try to combine both methods in the real experiment.

10

As a diagnostic aid in the three most recent PTB 3.0.17 betas since february 2021, there is one new visual way for a human observer (but not for PTB itself) to find out if sync failure is due to interference by the desktop compositor on Windows-10, or if the reason is a different one, e.g., generally bad/noisy system timing or other display driver bugs:

Screen('Preference','Visualdebuglevel', 6);

If the compositor is at work, and thereby the root cause of timing problems, the window will turn invisible - ie. you see the usual ptb output in the command window, but nothing on the screen, just the regular desktop GUI. This will, e.g., happen on HiDPI or mixed DPI displays if something is not optimal, on multi-display setups if something is not optimal, if Windows has a bad hair day, or if on an otherwise working multi-display setup the compositor kicks in in the middle of a session, e.g., because the user clicked on some gui window, the matlab window etc. ie. interacted in any way with the desktop GUI on the other monitor.

-mario