Error: Synchronization Failure

Programming Help
1

Dear community,

I’m new to Psychtoolbox and have encountered a screen sync problem when starting with my first tutorials. I noticed this is a common problem, and tried some solutions from answer found online but nothing has worked so far. I’m starting to think it might have to do with my hardware and wanted to check if there’s something I’m overlooking.

I’m using the following:

Psychtoolbox Version:
‘3.0.18 - Flavor: beta - Corresponds to SVN Revision 12626’
Windows 10
ASUS UX430UAR Laptot and ASUS VG248QE Full-HD Monitor
MATLAB R2017b
GPU: Intel(R) UHD Graphics 620

I tried running:

sca;
close all;
clear;

PsychDefaultSetup(2);

screens = Screen('Screens');
screenNumber = max(screens);

white = WhiteIndex(screenNumber);
black = BlackIndex(screenNumber);
grey = white / 2;

[window, windowRect] = PsychImaging('OpenWindow', screenNumber, grey);

KbStrokeWait;

sca;

and got the following error:

PTB-INFO: Multi-display setup in explicit multi-display mode detected. Using the following mapping:
PTB-INFO: Screen 0 corresponds to the full Windows desktop area. Useful for stereo presentations in stereomode=4 ...
PTB-INFO: Screen 1 corresponds to the display area of the monitor with the Windows-internal name \\.\DISPLAY1 ...
PTB-INFO: Screen 2 corresponds to the display area of the monitor with the Windows-internal name \\.\DISPLAY2 ...



PTB-INFO: This is Psychtoolbox-3 for Microsoft Windows, under Matlab 64-Bit (Version 3.0.18 - Build date: Nov 30 2021).
PTB-INFO: OS support status: Windows 10 (Version 10.0) supported and tested to some limited degree.
PTB-INFO: Type 'PsychtoolboxVersion' for more detailed version information.
PTB-INFO: Most parts of the Psychtoolbox distribution are licensed to you under terms of the MIT License, with
PTB-INFO: some restrictions. See file 'License.txt' in the Psychtoolbox root folder for the exact licensing conditions.

PTB-INFO: For information about paid priority support, community membership and commercial services, please type
PTB-INFO: 'PsychPaidSupportAndServices'.

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 Intel :: Intel(R) UHD Graphics 620 :: 4.6.0 - Build 27.20.100.8477
PTB-INFO: VBL startline = 1080 , VBL Endline = 1080
PTB-INFO: Measured monitor refresh interval from beamposition = 16.683427 ms [59.939725 Hz].
PTB-INFO: Will use beamposition query for accurate Flip time stamping.
PTB-INFO: Measured monitor refresh interval from VBLsync = 16.664968 ms [60.006116 Hz]. (50 valid samples taken, stddev=0.338679 ms.)
PTB-INFO: Reported monitor refresh interval from operating system = 16.949153 ms [59.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.


Error using Screen
See error message printed above.

Error in PsychImaging (line 2339)
            [win, winRect] = Screen('OpenWindow', screenid, clearcolor, winRect, pixelSize, numbuffers, stereomode, multiSample, imagingMode,
            specialFlags, clientRect, fbOverrideRect, vrrParams);

I have run ‘help SyncTrouble’ and tried the solutions for the reasons that might apply:

    1. Wrong configuration settings: my graphics card won’t allow customization
    1. Temporary timing glitches or system malfunction: Restarted Matlab and rebooted PC
    1. Driver bugs: updated graphic driver
    1. Driver/Hardware limitations: Second screen is in full screen mode and display is not mirrored. Also tried using only one screen.
    1. Graphics system overload: Tried lower display resolution
    1. General ​system overload: Closed all other apps
    1. Bad drivers or hardware in your system that interferes with general
      ​system timing: Not using MS-Windows

Please let me know if there seems to be something I could be overlooking, or a solution I haven’t tried. Thank you in advance!

2

It sound like you’ve tried most of the things possible on Windows, and this is an OS limitation. The solutions are to either ignore the precise timing support that PTB affords (use 1 to continue with a warning or 2 to remove the warning completely):

Screen('Preference', 'SkipSyncTests', 1);

…tweak the acceptable variance in the timing measurement (your error was 0.34ms, over the default limit of 0.2ms):

syncVariance = 4e-04; % the default is 2e-04 (0.2ms)
Screen('Preference','SyncTestSettings', syncVariance); %set acceptable variability

…but if you want to collect scientific data with solid timing, then you really should install Linux (you can dual boot)…

3

Thank you for the quick response, Ian! I will then try it with Linux.

1 Like
4

Just as a warning to anyone reading this advice by Ian,
Screen('Preference','SyncTestSettings', syncVariance); %set acceptable variability
should not be used unless you really know what it does and why, and you’ve thoroughly and competently verified with independent measures like advanced use of photo-diodes and similar equipment that your system works fine wrt. visual stimulation and all you try to fix here is some unusually high timing noise. Setting this value to, e.g., 0.5 msecs does not mean you are willing to accept 0.5 msecs timing errors during the experiment at all. It means that your are 100% confident (thanks to your very extensive low-level expert knowledge and measurements) that the, e.g., 0.4 msecs timing variability measured during self-tests and calibrations are not caused by any real visual timing problems, but are only system timing noise that can be safely ignored.

I’d assume the set of people who understand to use that setting reasonably safely without my explicit guidance tailored to any specific case is probably myself and maybe Ian.

The combination of Microsoft Windows + Intel graphics is unworkable wrt. visual stimulation timing on many (if not most?) hardware + Windows + Intel driver setups, with no known way to fix it - unless Intel at some day would release a driver update that would fix or improve things. My own Windows + Intel test machine proved unfixable, and not for lack of trying.

Upgrading to Linux (currently recommended Ubuntu 20.04.3-LTS under X11 X-Server, not Wayland) is the only recommended solution, and in my experience a very reliable one for excellent timing.

5

One thing to watch out for with WinTel setups is triple-buffering. Triple-buffering might be active even though it is neither advertised nor can it be disabled. In such a case, I found the following workaround useful:

kPsychBusyWaitForVBLBeforeBufferSwapRequest = 2^15;  
Screen('Preference', 'ConserveVRAM', kPsychBusyWaitForVBLBeforeBufferSwapRequest);

However, this workaround adds a consistent one-frame delay at the output, which is and cannot be detected by PTB, and it burns CPU time. But otherwise, the PTB flip timing is reliable and timestamps are consistent - well, at least with the single-screen setup I have tested. Note that programs that rely on swapping between only 2 buffers on a higher level, e.g. when preserving the information in the buffers for reusing it in subsequent frames, might need further tweaking for making them triple-buffer safe.

Here is a program that makes triple-buffering visible:

function TripleBufferCheck
% Check for triple buffering. 
% First, the program draws a patch in 3 consecutive frames at 3 positions on the screen - 1:left, 2:mid, 3:right.
% Then the program just flips between the buffers for a few seconds, without clearing the buffers in between.
% If there are only 2 buffers (aka double-buffering), we will see the patches flickering between 2 positions. 
% Otherwise, if we have triple-buffering, we will see patches flickering between all 3 positions. 
% There is also a small square at the top left that changes color while flipping.

    SCREEN_NO = 0;
    clear Screen
    Screen('Preference', 'VBLTimestampingMode', -1);    
    Screen('Preference', 'Verbosity', 3);
    Screen('Preference', 'VisualDebugLevel', 0);
    Screen('Preference', 'SkipSyncTests', 1); 
    try
        wnd = Screen('OpenWindow',SCREEN_NO,0);
        [w,h] = Screen('WindowSize', wnd);
        %--- Hide the mouse cursor, just in case there is some interference  
        %    between cursor drawing and buffering.
        HideCursor();
        for x=-1:1
            %--- Be sure that there are no pending flips anymore (at a very low 
            %    level). Don't rely on what PTB thinks is going on, because this 
            %    might be wrong due to triple-buffering.
            WaitSecs(50e-3,'YieldSecs');
            Screen('FillRect', wnd, 0);
            Screen('FillRect', wnd, 255, repmat([w/2+w/3*x,h/2],1,2) + w/16*[-1,-1,1,1]);
            Screen('Flip', wnd, 0, 2);
        end
        %--- Cycle through the buffers for a while in a consistent way, i.e. without 
        %    flipping potentially too fast for making every buffer show (with 
        %    triple-buffering, flip synchronization won't work correctly).
        alarm = GetSecs() + 4;
        while GetSecs()<alarm
            WaitSecs(50e-3,'YieldSecs');
            Screen('FillRect',wnd, round(rand(3,1)*255), [0,0,20,20]);
            Screen('Flip', wnd, 0, 2);            
        end
        ShowCursor();
        sca();
    catch e
        ShowCursor();
        sca();
        rethrow(e);
    end
end
6

That setting may help against broken hardware vsync, at drastically increased cpu load, but can not generally work around triple-buffering. Your “consistent one frame lag” will not be consistent at all in many common scenarios, so if that worked for you, it was a lucky special case - or you fooled yourself, depending on how you verified it.

I am not aware of a generally working solution for triple-buffering or n-buffering with n != 2 wrt. reliable timing, and i thought a lot about that in the past as well.

Your detection script may work to detect its presence in many cases if n == 3, but your workaround is not recommended to anybody reading this, unless they have a deep understanding of how modern gpu’s + drivers work and how that interacts with their paradigm.

On Linux, PTB can reliably detect triple-buffering if that is a problem, thanks to OS mechanisms that help. On recommended hw + drivers, n-buffering doesn’t matter at all for reliability and can be even used for performance/stability enhancement.

The advice for most people with timing or reliability needs is the same: Upgrade to Linux whenever possible, but especially for Intel graphics.

Back to vacation…
-mario

7

Btw., your TripleBufferCheck.m script did indicate triple-buffering on my Intel UHD Graphics 620 (Kabylake GT2) graphics chip, so at least on Windows-10/11 with Intel graphics, graphics/display driver induced triple-buffering seems to be the cause for broken visual timing, as opposed to other types of n-buffering which your script would not be able to detect. A bit of googling on Intel’s support website, forums etc. and a little tour through the MS-Windows registry suggests that triple buffering on current Intel drivers for modern Intel gpu’s can not be disabled on Windows. At least i could not find any clue on how, and could not find any related registry setting. This would mean that all modern Intel gpu’s under Windows have broken and unreliable visual stimulation timing/timestamping, not such a subset.

Your test script inspired me to build something like that into our startup tests: The startup/welcome screen will wiggle/shake/vibrate during the startup tests if such triple-buffering is active, as a visual indicator of the cause of a usually following sync failure.
Not on Linux though, where we have better diagnostics since many years and also triple-buffering is not harmful but sometimes helpful. The next PTB will have this for at least Octave on Windows/macOS and Matlab on macOS. The Matlab version for Windows may follow later.

Thanks for the inspiration/idea,
-mario