# installation probs **URL:** \ **Category:** Uncategorized\ **Created:** [December 30, 2012, 5:40pm UTC](https://psychtoolbox.discourse.group/t/installation-probs/375 "2012-12-30T17:40:59Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![smgxjas](https://avatars.discourse-cdn.com/v4/letter/s/e9a140/32.png) [@smgxjas](https://psychtoolbox.discourse.group/u/smgxjas)\ **Post date:** [December 30, 2012, 5:40pm UTC](https://psychtoolbox.discourse.group/t/installation-probs/375/1 "2012-12-30T17:40:59Z")
new computer. matlab 2012b. 64-bit mac running mountain lion. tried running the latest DownloadPsychToolbox.m got this: > \>\> DownloadPsychtoolbox DownloadPsychtoolbox('/Applications','beta','') Requested flavor is: beta Requested location for the Psychtoolbox folder is inside: /Applications Will use the svn client which is located in this folder: /usr/local/bin/ Good. Your privileges suffice for the requested installation into folder /Applications. I will now download the latest Psychtoolbox for OSX. Requested flavor is: beta Target folder for installation: /Applications The following CHECKOUT command asks the Subversion client to download the Psychtoolbox: /usr/local/bin/svn checkout https://github.com/Psychtoolbox-3/Psychtoolbox-3/branches/beta/Psychtoolbox / "/Applications/Psychtoolbox" Downloading. It's nearly 100 MB, which can take many minutes. Alas there may be no output to this window to indicate progress until the download is complete. Please be patient ... If you see some message asking something like "accept certificate (p)ermanently, (t)emporarily? etc." then please press the p key on your keyboard, possibly followed by pressing the ENTER key. Error validating server certificate for 'https://github.com:443': - The certificate is not issued by a trusted authority. Use the fingerprint to validate the certificate manually! Certificate information: - Hostname: github.com - Valid: from May 27 00:00:00 2011 GMT until Jul 29 12:00:00 2013 GMT - Issuer: www.digicert.com, DigiCert Inc, US - Fingerprint: ce:67:99:25:2c:ac:78:12:7d:94:b5:62:2c:31:c5:16:a6:34:73:53 (R)eject, accept (t)emporarily or accept (p)ermanently? p subversion/libsvn\_ra\_dav/util.c:826: (apr\_err=175002) svn: PROPFIND request failed on '/Psychtoolbox-3/Psychtoolbox-3/branches/beta/Psychtoolbox' subversion/libsvn\_ra\_dav/util.c:296: (apr\_err=175002) svn: PROPFIND of '/Psychtoolbox-3/Psychtoolbox-3/branches/beta/Psychtoolbox': Could not read status line: Secure connection truncated (https://github.com) Sorry, the download command "CHECKOUT" failed with error code 1: For reason, see output above. The download failure might be due to temporary network or server problems. You may want to try again in a few minutes. It could also be that the subversion client was not (properly) installed. On Microsoft Windows you will need to exit and restart Matlab or Octave after installation of the Subversion client. If that does not help, you will need to reboot your machine before proceeding. Another reason for download failure could be if an old working copy - a Psychtoolbox folder - still exists. In that case, it may help to manually delete that folder. Or maybe you do not have write permissions for the target folder? Error using DownloadPsychtoolbox (line 765) Download failed. ideas? -- Joshua A. Solomon http://www.staff.city.ac.uk/~solomon ---
**Author:** ![mariokleiner](https://avatars.discourse-cdn.com/v4/letter/m/13edae/32.png) [@mariokleiner](https://psychtoolbox.discourse.group/u/mariokleiner)\ **Post date:** [December 30, 2012, 6:45pm UTC](https://psychtoolbox.discourse.group/t/installation-probs/375/2 "2012-12-30T18:45:08Z")
> \> The download failure might be due to temporary network or server problems. > \> You may want to try again in a > \> few minutes. https://status.github.com/messages > --- In psychtoolbox@yahoogroups.com, "Solomon, Joshua" \ wrote: > \> > \> new computer. matlab 2012b. 64-bit mac running mountain lion. tried > \> running the latest DownloadPsychToolbox.m > \> got this: > \> > \> \>\> DownloadPsychtoolbox > \> DownloadPsychtoolbox('/Applications','beta','') > \> Requested flavor is: beta > \> Requested location for the Psychtoolbox folder is inside: /Applications > \> > \> Will use the svn client which is located in this folder: /usr/local/bin/ > \> Good. Your privileges suffice for the requested installation into folder > \> /Applications. > \> > \> I will now download the latest Psychtoolbox for OSX. > \> Requested flavor is: beta > \> Target folder for installation: /Applications > \> The following CHECKOUT command asks the Subversion client to > \> download the Psychtoolbox: > \> /usr/local/bin/svn checkout > \> https://github.com/Psychtoolbox-3/Psychtoolbox-3/branches/beta/Psychtoolbox > \> / "/Applications/Psychtoolbox" > \> Downloading. It's nearly 100 MB, which can take many minutes. > \> Alas there may be no output to this window to indicate progress until the > \> download is complete. > \> Please be patient ... > \> If you see some message asking something like "accept certificate > \> (p)ermanently, (t)emporarily? etc." > \> then please press the p key on your keyboard, possibly followed by > \> pressing the ENTER key. > \> > \> Error validating server certificate for 'https://github.com:443': > \> - The certificate is not issued by a trusted authority. Use the > \> fingerprint to validate the certificate manually! > \> Certificate information: > \> - Hostname: github.com > \> - Valid: from May 27 00:00:00 2011 GMT until Jul 29 12:00:00 2013 GMT > \> - Issuer: www.digicert.com, DigiCert Inc, US > \> - Fingerprint: ce:67:99:25:2c:ac:78:12:7d:94:b5:62:2c:31:c5:16:a6:34:73:53 > \> (R)eject, accept (t)emporarily or accept (p)ermanently? p > \> subversion/libsvn\_ra\_dav/util.c:826: (apr\_err=175002) > \> svn: PROPFIND request failed on > \> '/Psychtoolbox-3/Psychtoolbox-3/branches/beta/Psychtoolbox' > \> subversion/libsvn\_ra\_dav/util.c:296: (apr\_err=175002) > \> svn: PROPFIND of > \> '/Psychtoolbox-3/Psychtoolbox-3/branches/beta/Psychtoolbox': Could not > \> read status line: Secure connection truncated (https://github.com) > \> Sorry, the download command "CHECKOUT" failed with error code 1: > \> For reason, see output above. > \> The download failure might be due to temporary network or server problems. > \> You may want to try again in a > \> few minutes. It could also be that the subversion client was not > \> (properly) installed. On Microsoft > \> Windows you will need to exit and restart Matlab or Octave after > \> installation of the Subversion client. If that > \> does not help, you will need to reboot your machine before proceeding. > \> Another reason for download failure could be if an old working copy - a > \> Psychtoolbox folder - still exists. > \> In that case, it may help to manually delete that folder. Or maybe you do > \> not have write permissions for the target folder? > \> > \> Error using DownloadPsychtoolbox (line 765) > \> Download failed. > \> > \> ideas? > \> > \> -- > \> Joshua A. Solomon > \> http://www.staff.city.ac.uk/~solomon > \> ---
**Author:** ![smgxjas](https://avatars.discourse-cdn.com/v4/letter/s/e9a140/32.png) [@smgxjas](https://psychtoolbox.discourse.group/u/smgxjas)\ **Post date:** [January 1, 2013, 3:29pm UTC](https://psychtoolbox.discourse.group/t/installation-probs/375/3 "2013-01-01T15:29:52Z")
On 30/12/2012 22:11, "Mario" \<[mario.kleiner@...](mailto:mario.kleiner@...)\> wrote: > \>You can also get it directly from GitHub that worked, thanks. problems persist, however: > \>\> DriftDemo6 PTB-INFO: This is Psychtoolbox-3 for Apple OS X, under Matlab 64-Bit (Version 3.0.10 - Build date: Oct 29 2012). 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: Broken Apple OS/X 10.7 or later detected: Using CoreVideo timestamping instead of precise vbl-irq timestamping. PTB-WARNING: Querying rasterbeam-position doesn't work on your setup! (Returns a constant value 1800) PTB-WARNING: This can happen if Psychtoolbox gets the mapping of connected displays to graphics card PTB-WARNING: outputs wrong. See 'help DisplayOutputMappings' for tips on how to resolve this problem. PTB-INFO: OpenGL-Renderer is NVIDIA Corporation :: NVIDIA GeForce GT 650M OpenGL Engine :: 2.1 NVIDIA-8.6.22 PTB-INFO: Renderer has 1024 MB of VRAM and a maximum 991 MB of texture memory. PTB-INFO: VBL startline = 900 , VBL Endline = -1 PTB-INFO: Beamposition queries unsupported on this system. Will try to use kernel-level vbl interrupts as fallback. PTB-INFO: Measured monitor refresh interval from VBLsync = 16.683959 ms [59.937813 Hz]. (299 valid samples taken, stddev=0.712099 ms.) PTB-INFO: Small deviations between reported values are normal and no reason to worry. ----- ! PTB - WARNING: SYNCHRONIZATION TROUBLE ! ---- One or more internal checks (see Warnings above) indicate that queries of rasterbeam position are not properly working for your setup. Psychtoolbox will work around this by using a different timing algorithm, but it will cause Screen('Flip') to report less accurate/robust timestamps for stimulus timing. Read 'help BeampositionQueries' for more info and troubleshooting tips. PTB-INFO: Support for fast OffscreenWindows enabled. Building a fragment shader:Reading shader from file /Applications/Psychtoolbox/PsychOpenGL/PsychGLSLShaders/SeparateAlphaTextur eShader.frag.txt ... Building a vertex shader:Reading shader from file /Applications/Psychtoolbox/PsychOpenGL/PsychGLSLShaders/SeparateAlphaTextur eShader.vert.txt ... INFO: PTB's Screen('Flip', 10) command seems to have missed the requested stimulus presentation deadline INFO: a total of 297 times out of a total of 297 flips during this session. INFO: This number is fairly accurate (and indicative of real timing problems in your own code or your system) INFO: if you provided requested stimulus onset times with the 'when' argument of Screen('Flip', window [, when]); INFO: If you called Screen('Flip', window); without the 'when' argument, this count is more of a ''mild'' indicator INFO: of timing behaviour than a hard reliable measurement. Large numbers may indicate problems and should at least INFO: deserve your closer attention. Cfe. 'help SyncTrouble', the FAQ section at www.psychtoolbox.org and the INFO: examples in the PDF presentation in PsychDocumentation/Psychtoolbox3-Slides.pdf for more info and timing tips. (end of DriftDemo6 output) note that after the exclamation point, which i assume accompanies the "PTB - WARNING," i saw DriftDemo6's two gratings and they looked OK. nonetheless, as suggested, i tried > \>\> help DisplayOutputMappings DisplayOutputMappings -- How they work, how to resolve problems. You probably read this text, because Screen() gave you some error or warning message about problems with beamposition queries or other low-level functions and directed you to this document for troubleshooting. So, what happened here? For various low-level operations, e.g., beamposition queries for timestamping, control of high precision framebuffers and high precision display devices, and for certain stereo display modes, Screen() needs to know which video output connector on your graphics card is connected to which electronic display scanout engine (a so called "crtc") in the graphics card, because it needs to exercise low-level control over the crtc associated with a specific display. The actual wiring between crtc's and display connectors however is not fixed on modern graphics cards, but it is flexible. The wiring is controlled by electronic programmable switches, so called multiplexers ("MUXers"), which are configured by the operating system and graphics card driver. Depending on the specific hardware, operating system and display setup, the wiring can change dynamically. You can find more technical details at the following links if you are interested: \<[http://www.botchco.com/agd5f/?p=51](http://www.botchco.com/agd5f/?p=51)\> for AMD/ATI hardware, and \<[http://virtuousgeek.org/blog/index.php/jbarnes/2011/01/](http://virtuousgeek.org/blog/index.php/jbarnes/2011/01/)\> for Intel hardware. Sometimes, due to operating system or graphics driver bugs, or system misconfiguration, the operating system "lies" to Screen() about the true wiring. On some systems, the operating system can't tell Screen() about the wiring and Screen() has to make an educated guess based on some heuristics - a guess which can go wrong. Long story short, Screen() can be wrong about which crtc to access for a given display, causing the kind of malfunctions, warnings and errors messages that brought you to this help text. To fix such problems you need to help Screen() in one of multiple different ways: 1. On MS-Windows, try to update your graphics driver in the hope that this fixes the problem. Don't forget to reboot! 2. If this doesn't help, or if you are on Linux or OS/X, try to replug the displays into different video output connectors on your computer. E.g., on a single monitor setup, plug the monitor into the other video output connector. On a dual-display setup, exchange which monitor is plugged into which connector etc. This replugging will make reality match the expectations of Screen(). Don't forget to restart Matlab or Octave after the change. 3. If 2. doesn't help or is infeasible or problematic, you can also tell Screen() about the true wiring by adding the command Screen('Preference', 'ScreenToHead', screen, head, crtc[, rank]); to the top of your script, before other Screen() commmands: On OS/X or Windows, Screen('Preference', 'ScreenToHead', 0, 1, 1); would tell Screen() that the Psychtoolbox screen with screenid 0 is not connected to video output 0 and crtc 0 (as would be the default), but to video output 1 and crtc 1. On Linux the same logic applies. However, on Linux, multiple video outputs (and thereby display monitors) can be connected to one single Psychtoolbox screenid (aka X-Window system X-Screen) to allow for more flexibility than on the other systems. For this reason an additional 'rank' parameter controls which of multiple possible outputs per screen is remapped. The default 'rank' of 0 refers to the primary display output, the one which is used for stimulus onset timestamping or framerate queries. It may therefore be neccessary to play with the 'rank' parameter as well on multi-display setups with multiple monitors per Psychtoolbox screen. 4. If you have a multi-GPU setup, ie., multiple graphics cards installed and active at the same time, then Screen() low-level functions may not work. More precisely, they will not work at all on MS-Windows or Apple OS/X. On Linux you can make them work on exactly one GPU, the other GPU's will be ignored. By default, the first GPU in the system is chosen. You can override the choice by setting a Unix environment variable PSYCH\_USE\_GPUIDX, e.g., the command... export PSYCH\_USE\_GPUIDX=1 ; matlab ... would start Matlab and instruct Screen() to use the GPU with index 1, which is the 2nd GPU in the system, as numbering starts with zero for the 1st GPU. Good luck with troubleshooting! (end of help DisplayOutputMappings output) note that neither 1, 2, nor 3 (above) seem to apply, because i'm using a MacBook Pro that isn't connected to anything else. 4 (above) says it doesn't work on OS/X. so i then tried > \>\> help BeampositionQueries BeampositionQueries -- What they are used for, and what can go wrong. MacOS-X and M$-Windows provide a mechanism that allows to query the scanline which is currently updated by the scanning beam of a CRT display or by the equivalent mechanism in a video beamer or flat panel display, the so called "beamposition". We use this mechanism for two purposes: 1. Independent measurement of the monitor refresh interval: Psychtoolbox executes a measurement loop during Screen('OpenWindow') where it determines the monitor refresh interval. It takes a timestamp whenever the beamposition resets to zero at the start of a new display refresh cycle. The difference between consecutive timestamps is a sample of refresh duration. The samples of 50 consecutive refresh cycles are averaged. The "length" of the VBL is also computed as the difference between screen height (e.g., 1024 at a display resolution of 1280 x 1024 pixels) and the highest scanline value encountered during the 50 refresh cycles. This measurement is used to cross-check the results of the synchronization tests (see 'help SyncTrouble') and the value provided by the operating system to make the sync tests and display calibration as robust as possible, even if the operating system reports bogus values like 0 Hz, which can happen on MacOS-X and Windows with some flat panels. 2. Highly accurate and robust stimulus onset timestamps in Screen('Flip'). In normal operation, the Screen('Flip') command, after issuing a buffer-swap request to the gfx-hardware, pauses execution until the operating system signals swap-completion in sync with vertical retrace. Then it takes a high- precision system timestamp. Due to the scheduling jitter present in any operating system, sometimes the execution of Psychtoolbox is resumed only after some random multi-millisecond delay has passed after buffer-swap, so the stimulus onset timestamp can be possibly off by multiple milliseconds from the real stimulus onset time. This is unwanted timing noise, especially if the time stamp is to be used for either computing stimulus onset time for future stimuli, or for synchronizing Psychtoolbox execution with other stimulus generators or acquisition hardware. On Microsoft Windows 2000 and later, there is experimental support for beamposition queries. This support is only enabled on single display setups and multi-display setups which are configured to appear to Psychtoolbox as single-display setups, i.e., one "virtual" primary monitor which consists of multiple real displays in horizontal spanning mode. We use this mechanism to get high precision time stamps as the ones described below for MacOS-X. On GNU/Linux, timing precision even in non-realtime scheduling mode is far superior to all other operating systems, yielding a timing jitter of less than 100 microseconds under normal operating conditions. For special needs, there exist multiple methods of improving timing down to microsecond level, although some of time require some advanced programming skills. If Psychtoolbox runs on an ATI graphics card of the X1000 series or HD xxxx series and Matlab/Octave is run with superuser privileges, Psychtoolbox will also utilize beamposition queries for even better timing precision. On other graphics cards, this is not yet supported. On MacOS-X, whose timing accuracy is somewhere between Linux and Windows, and luckily closer to Linux timing than to Windows timing, we use beamposition queries to improve accuracy of our timestamps, either with the native support on PowerPC computers and IntelMacs with NVidia or Intel graphics, or with the help of the PsychtoolboxKernelDriver (see help PsychtoolboxKernelDriver) on cards from ATI. An alternative mechanism, based on vertical blank interrupts, is implemented on OS/X, should the beamposition mechanism malfunction or become unavailable. This is how beamposition queries are used: When taking the system timestamp, we also query the current rasterbeam position. From the known height of the display (in scanlines, including height of VBL), and the known refresh interval of our display, we can translate the current beam position into "elapsed time since start of VBL == elapsed time since double buffer swap". By subtracting this elapsed time value from our system timestamp, we get a corrected timestamp - the real system time of double buffer swap == start of VBL == aka stimulus onset. This allows for very accurate timestamps, despite possible non-deterministic multi-millisecond timing jitter. Psychtoolbox goes through great pains during startup to double-check that all required calibration values and mechanisms are accurate and working properly. You can assess the accuracy of all returned timestamps by use of the script VBLSyncTest. A visual correctness test is provided by PerceptualVBLSyncTest. PTB also performs continuous runtime checking to detect possible problems caused by defective graphics card drivers. In case that beamposition queries should not work properly or are not supported, PTB will use different fallback strategies: On Microsoft Windows, only a normal - possibly noisy - timestamp is taken. On MacOS-X, PTB tries to get low-level access to the kernel interrupt handlers for the VBL interrupts and uses its values for timestamping the time of buffer- swap. This method is slightly less accurate and robust than the bemposition method, but should be still suitable for most applications. If the kernel-level queries should fail as well, PTB falls back to pure timestamping without any correction. The behaviour of PTB can be controlled by the command: Screen('Preference', 'VBLTimestampingMode', mode); where mode can be one of the following: -1 = Disable all cleverness, take noisy timestamps. This is the behaviour you'd get from any other psychophysics toolkit, as far as we know. 0 = Disable kernel-level fallback method (on OS-X), use either beamposition or noisy stamps if beamposition is unavailable. 1 = Use beamposition. Should it fail, switch to use of kernel-level interrupt timestamps. If that fails as well or is unavailable, use noisy stamps. 2 = Use beamposition, but cross-check with kernel-level timestamps. Use noisy stamps if beamposition mode fails. This is for the paranoid to check proper functioning. 3 = Always use kernel-level timestamping, fall back to noisy stamps if it fails. 4 = Use OpenML OML\_sync\_control extension for high-precision timestamping on supported system configuration. This is currently a Linux only feature on some specific systems. It is considered experimental for now. The default on OS-X, Linux and Windows with single display setups is "1". On Windows in explicit multi-display mode, we default to "-1" ie. noisy timestamps if you are running Psychtoolbox under a Matlab version older than R2007a, as the current beamposition mechanism is not capable of supporting multi-display setups due to some limitations imposed by old Matlab versions. On modern Matlab's or Octave, the accurate mode "1" is used as well. On Linux and OS/X the accurate mode "1" is also used on multi-display setups. If the beampos query test fails, you will see some warning message about "SYNCHRONIZATION TROUBLE" in the Matlab/Octave command window or other error messages, as diagnostics is performed at various stages of setup and operation. There are two possible causes for failure: 1. System overload: Too many other applications are running in parallel to Psychtoolbox, introducing severe timing noise into the calibration and test loop. See 'help SyncTrouble' on what to do. This happens rather seldomly. 2. Driver bug: Not much you can do, except submit a bug report to Apple or Microsoft for your specific hardware + software setup. This is by far the most common cause of failure. Psychtoolbox tries to enable work-arounds for some common problems if possible. Usually you should update your graphics card driver to see if that resolves the problems. Note: As of Spring/Summer 2008, many graphics cards + driver combos from ATI and NVidia on WindowsXP have bugs which cause beamposition queries to fail in a peculiar way. If PTB detects that failure case, it will enable some workaround to keep the mechanism going at slightly reduced accuracy: Timestamps will still be mostly jitter-free and consistent, so they are fully useable for timestamping, timing checks and as a basis for timed stimulus presentation and animation. However, all returned timestamps will contain a constant bias wrt. the real stimulus onset time of somewhere between 20 microseconds and 1.5 milliseconds, depending on your display settings, because Psychtoolbox can't determine the total height of your display in scanlines (including the invisible VBL interval) anymore. Exact height is important for spot-on timestamps. Psychtoolbox uses some safe, conservative value for its internal computations, so results will be consistent and useable, but contain a small constant offset. In some rare cases, PTB's automatic test fails to detect the bug and doesn't enable the workaround by itself. You can manually enable the workaround if you want by adding the setting 4096 (kPsychUseBeampositionQueryWorkaround) to the value x passed via: Screen('Preference', 'ConserveVRAM', x); Just insert this command at the top of your scripts before any other Screen() commands. 'x' must be at least 4096 or the sum of 4096 and any other values you may want to pass with that command. See "help ConserveVRAMSettings" for other workarounds that you can enable manually if needed. If you want to get rid of that small offset, e.g., because you need to synchronize with other modalities or stimulation/recording equipment at sub-millisecond precisison, then you can try to figure out the real height of the display yourself and tell Psychtoolbox about the true value before calling Screen('OpenWindow'). Once you know the real height, e.g., VTOTAL, you'd call this function: Screen('Preference', 'VBLEndlineOverride', VTOTAL); How to find out about VTOTAL? One way is to search the display control panel on Windows for some area with "Advanced Timing" or "Custom Timing" settings. The shareware utility "PowerStrip" ([http://www.entechtaiwan.com/util/ps.shtm)](http://www.entechtaiwan.com/util/ps.shtm)) also allows to change and display these parameters in the Advanced Timing -\> Vertical Geometry -\> "Total" field. Accuracy of beamposition method: Cross-checking of beamposition timestamps and kernel-level timestamps on a single display PowerPC G5 1.6 Ghz under OS-X 10.4.8 with NVidia GeforceFX-5200 showed an accuracy of beamposition timestamping of better than 100 microseconds, with a maximum deviation between the different methods of less than 200 microseconds. Initial checking on two Window PC's (Dell Inspiron 8000 Laptop, Geforce 2Go, Windows 2000, and some 3.2 Ghz Pentium-4 with NVidia Geforce 7800 GTX) shows a precision of about 30 microseconds. No further testing on Windows has been performed yet by us, but multiple users performed similar testing procedures on their setups and confirmed the high accuracy and reliability for various MacOSX and Windows setups. Also check the FAQ section of [http://www.psychtoolbox.org](http://www.psychtoolbox.org) for latest infos. (end of help BeampositionQueries output) note that i'm not quite sure how to update my graphics driver, but the app store indicates my system software is up-to-date. is there anything else i should check, or can i just ignore the WARNING and assume that synchronisation is really fine? j -- Joshua A. Solomon [http://www.staff.city.ac.uk/~solomon](http://www.staff.city.ac.uk/~solomon) ---
**Author:** ![mariokleiner](https://avatars.discourse-cdn.com/v4/letter/m/13edae/32.png) [@mariokleiner](https://psychtoolbox.discourse.group/u/mariokleiner)\ **Post date:** [January 2, 2013, 2:23pm UTC](https://psychtoolbox.discourse.group/t/installation-probs/375/4 "2013-01-02T14:23:03Z")
That's the same as reported by Ian: \<[https://gist.github.com/4151623](https://gist.github.com/4151623)\> Is this a MacBookPro Retina? What is its maximum resolution? Is the display resolution set to maximum or something lower? If you run BeampositionTest.m, how do the plots look like? Correct would be one plot with a sawtooth pattern, one histogram with somewhat evely filled bins, and two other plots. Bad would be a histogram with all values in the "1800" bin and a plot with a flat constant line at 1800. The proper way to solve it, assuming it is the OSX graphics driver bug i suspect it is, would be to install the PsychtoolboxKernelDriver ("help PsychtoolboxKernelDriver") on your machine, and then force ptb to use it in each session, by adding a: v = bitor(2^16, Screen('Preference','ConserveVRAM')); Screen('Preference','ConserveVRAM', v); ... to the top of each of your scripts - or to the Matlab startup file startup.m This would force Screen() to use the beamposition mechanism implemented in the PsychtoolboxKernelDriver, instead of the OSX native mechanism which usually gets preferred if both are available, and which is supposedly broken on your machine. If you don't do this, then PTB will use CoreVideo timestamping instead as a fallback, which is less accurate and robust, and is itself pretty buggy on many Apple machines. I'm contemplating to remove that mechanism completely, given how buggy it is. Or you just ignore the warnings and live with timestamps that are inacccurate at best or unreliable or totally wrong at worst. But please provide all info, and the output of Screen('Computer') anyway. Maybe i can find a way for a future beta release to detect the broken MacBookPro's so ptb switches automatically to the kernel driver method. In general the presentation timing of the Retina MBP's seems to be pretty poor. Both your machine and Ian's machine show very noisy raw measurements. Also the DriftDemo6 seems to miss all presentation deadlines on a task that shouldn't be very taxing on the graphics card. I don't know if it is just a badly implemented graphics driver or if the whole operating system is that noisy, but both of you run 10.8 and timing has degraded with pretty much each OSX release since the golden days of 10.4 when Apple still knew or cared to put attention to technical details other than roundness of round corners on black rectangles. -mario > --- In [psychtoolbox@yahoogroups.com](mailto:psychtoolbox@yahoogroups.com), "Solomon, Joshua" \ wrote: > \> > \> On 30/12/2012 22:11, "Mario" \ wrote: > \> > \> > \> \>You can also get it directly from GitHub > \> > \> that worked, thanks. problems persist, however: > \> > \> \>\> DriftDemo6 > \> > \> > \> PTB-INFO: This is Psychtoolbox-3 for Apple OS X, under Matlab 64-Bit > \> (Version 3.0.10 - Build date: Oct 29 2012). > \> 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: Broken Apple OS/X 10.7 or later detected: Using CoreVideo > \> timestamping instead of precise vbl-irq timestamping. > \> > \> PTB-WARNING: Querying rasterbeam-position doesn't work on your setup! > \> (Returns a constant value 1800) > \> PTB-WARNING: This can happen if Psychtoolbox gets the mapping of connected > \> displays to graphics card > \> PTB-WARNING: outputs wrong. See 'help DisplayOutputMappings' for tips on > \> how to resolve this problem. > \> > \> > \> > \> PTB-INFO: OpenGL-Renderer is NVIDIA Corporation :: NVIDIA GeForce GT 650M > \> OpenGL Engine :: 2.1 NVIDIA-8.6.22 > \> PTB-INFO: Renderer has 1024 MB of VRAM and a maximum 991 MB of texture > \> memory. > \> PTB-INFO: VBL startline = 900 , VBL Endline = -1 > \> PTB-INFO: Beamposition queries unsupported on this system. Will try to use > \> kernel-level vbl interrupts as fallback. > \> PTB-INFO: Measured monitor refresh interval from VBLsync = 16.683959 ms > \> [59.937813 Hz]. (299 valid samples taken, stddev=0.712099 ms.) > \> PTB-INFO: Small deviations between reported values are normal and no > \> reason to worry. > \> > \> > \> ----- ! PTB - WARNING: SYNCHRONIZATION TROUBLE ! ---- > \> > \> One or more internal checks (see Warnings above) indicate that > \> queries of rasterbeam position are not properly working for your setup. > \> > \> Psychtoolbox will work around this by using a different timing algorithm, > \> but it will cause Screen('Flip') to report less accurate/robust timestamps > \> for stimulus timing. > \> Read 'help BeampositionQueries' for more info and troubleshooting tips. > \> > \> > \> PTB-INFO: Support for fast OffscreenWindows enabled. > \> Building a fragment shader:Reading shader from file > \> /Applications/Psychtoolbox/PsychOpenGL/PsychGLSLShaders/SeparateAlphaTextur > \> eShader.frag.txt ... > \> Building a vertex shader:Reading shader from file > \> /Applications/Psychtoolbox/PsychOpenGL/PsychGLSLShaders/SeparateAlphaTextur > \> eShader.vert.txt ... > \> > \> > \> INFO: PTB's Screen('Flip', 10) command seems to have missed the requested > \> stimulus presentation deadline > \> INFO: a total of 297 times out of a total of 297 flips during this session. > \> > \> INFO: This number is fairly accurate (and indicative of real timing > \> problems in your own code or your system) > \> INFO: if you provided requested stimulus onset times with the 'when' > \> argument of Screen('Flip', window [, when]); > \> INFO: If you called Screen('Flip', window); without the 'when' argument, > \> this count is more of a ''mild'' indicator > \> INFO: of timing behaviour than a hard reliable measurement. Large numbers > \> may indicate problems and should at least > \> INFO: deserve your closer attention. Cfe. 'help SyncTrouble', the FAQ > \> section at www.psychtoolbox.org and the > \> INFO: examples in the PDF presentation in > \> PsychDocumentation/Psychtoolbox3-Slides.pdf for more info and timing tips. > \> > \> (end of DriftDemo6 output) > \> > \> > \> note that after the exclamation point, which i assume accompanies the "PTB > \> - WARNING," i saw DriftDemo6's two gratings and they looked OK. > \> nonetheless, as suggested, i tried > \> > \> \>\> help DisplayOutputMappings > \> DisplayOutputMappings -- How they work, how to resolve problems. > \> > \> You probably read this text, because Screen() gave you some error or > \> warning message about problems with beamposition queries or other > \> low-level functions and directed you to this document for > \> troubleshooting. > \> > \> So, what happened here? > \> > \> For various low-level operations, e.g., beamposition queries for > \> timestamping, control of high precision framebuffers and high precision > \> display devices, and for certain stereo display modes, Screen() needs to > \> know which video output connector on your graphics card is connected to > \> which electronic display scanout engine (a so called "crtc") in the > \> graphics card, because it needs to exercise low-level control over the > \> crtc associated with a specific display. The actual wiring between crtc's > \> and display connectors however is not fixed on modern graphics cards, but > \> it is flexible. The wiring is controlled by electronic programmable > \> switches, so called multiplexers ("MUXers"), which are configured by the > \> operating system and graphics card driver. Depending on the specific > \> hardware, operating system and display setup, the wiring can change > \> dynamically. > \> > \> You can find more technical details at the following links if you are > \> interested: \<[http://www.botchco.com/agd5f/?p=51](http://www.botchco.com/agd5f/?p=51)\> for AMD/ATI hardware, > \> and \<[http://virtuousgeek.org/blog/index.php/jbarnes/2011/01/](http://virtuousgeek.org/blog/index.php/jbarnes/2011/01/)\> for Intel > \> hardware. > \> > \> > \> Sometimes, due to operating system or graphics driver bugs, or system > \> misconfiguration, the operating system "lies" to Screen() about the true > \> wiring. On some systems, the operating system can't tell Screen() about > \> the > \> wiring and Screen() has to make an educated guess based on some > \> heuristics - a guess which can go wrong. > \> > \> Long story short, Screen() can be wrong about which crtc to access for a > \> given display, causing the kind of malfunctions, warnings and errors > \> messages that brought you to this help text. To fix such problems you > \> need to help Screen() in one of multiple different ways: > \> > \> 1. On MS-Windows, try to update your graphics driver in the hope that > \> this fixes the problem. Don't forget to reboot! > \> > \> 2. If this doesn't help, or if you are on Linux or OS/X, try to replug > \> the displays into different video output connectors on your computer. > \> E.g., on a single monitor setup, plug the monitor into the other video > \> output connector. On a dual-display setup, exchange which monitor is > \> plugged into which connector etc. This replugging will make reality > \> match the expectations of Screen(). Don't forget to restart Matlab or > \> Octave after the change. > \> > \> 3. If 2. doesn't help or is infeasible or problematic, you can also tell > \> Screen() about the true wiring by adding the command > \> Screen('Preference', 'ScreenToHead', screen, head, crtc[, rank]); to > \> the > \> top of your script, before other Screen() commmands: > \> > \> On OS/X or Windows, Screen('Preference', 'ScreenToHead', 0, 1, 1); > \> would tell Screen() that the Psychtoolbox screen with screenid 0 is > \> not connected to video output 0 and crtc 0 (as would be the default), > \> but to video output 1 and crtc 1. > \> > \> On Linux the same logic applies. However, on Linux, multiple video > \> outputs (and thereby display monitors) can be connected to one single > \> Psychtoolbox screenid (aka X-Window system X-Screen) to allow for more > \> flexibility than on the other systems. For this reason an additional > \> 'rank' parameter controls which of multiple possible outputs per > \> screen is remapped. The default 'rank' of 0 refers to the primary > \> display output, the one which is used for stimulus onset timestamping > \> or framerate queries. It may therefore be neccessary to play with the > \> 'rank' parameter as well on multi-display setups with multiple > \> monitors per Psychtoolbox screen. > \> > \> 4. If you have a multi-GPU setup, ie., multiple graphics cards installed > \> and active at the same time, then Screen() low-level functions may > \> not work. More precisely, they will not work at all on MS-Windows or > \> Apple OS/X. On Linux you can make them work on exactly one GPU, the > \> other GPU's will be ignored. By default, the first GPU in the system > \> is chosen. You can override the choice by setting a Unix environment > \> variable PSYCH\_USE\_GPUIDX, e.g., the command... > \> export PSYCH\_USE\_GPUIDX=1 ; matlab > \> ... would start Matlab and instruct Screen() to use the GPU with index > \> 1, which is the 2nd GPU in the system, as numbering starts with zero > \> for the 1st GPU. > \> > \> > \> Good luck with troubleshooting! > \> > \> (end of help DisplayOutputMappings output) > \> > \> > \> note that neither 1, 2, nor 3 (above) seem to apply, because i'm using a > \> MacBook Pro that isn't connected to anything else. 4 (above) says it > \> doesn't work on OS/X. so i then tried > \> > \> \>\> help BeampositionQueries > \> BeampositionQueries -- What they are used for, and what can go wrong. > \> > \> MacOS-X and M$-Windows provide a mechanism that allows to query the > \> scanline which is currently updated by the scanning beam of a CRT > \> display or by the equivalent mechanism in a video beamer or flat > \> panel display, the so called "beamposition". > \> > \> We use this mechanism for two purposes: > \> > \> 1. Independent measurement of the monitor refresh interval: Psychtoolbox > \> executes a measurement loop during Screen('OpenWindow') where it > \> determines > \> the monitor refresh interval. It takes a timestamp whenever the > \> beamposition > \> resets to zero at the start of a new display refresh cycle. The > \> difference > \> between consecutive timestamps is a sample of refresh duration. The > \> samples > \> of 50 consecutive refresh cycles are averaged. The "length" of the VBL > \> is also computed as the difference between screen height (e.g., 1024 at a > \> display resolution of 1280 x 1024 pixels) and the highest scanline value > \> encountered during the 50 refresh cycles. > \> > \> This measurement is used to cross-check the results of the > \> synchronization tests > \> (see 'help SyncTrouble') and the value provided by the operating system > \> to > \> make the sync tests and display calibration as robust as possible, even > \> if the operating system reports bogus values like 0 Hz, which can happen > \> on MacOS-X and Windows with some flat panels. > \> > \> 2. Highly accurate and robust stimulus onset timestamps in > \> Screen('Flip'). > \> > \> In normal operation, the Screen('Flip') command, after issuing a > \> buffer-swap > \> request to the gfx-hardware, pauses execution until the operating system > \> signals swap-completion in sync with vertical retrace. Then it takes a > \> high- > \> precision system timestamp. Due to the scheduling jitter present in any > \> operating system, sometimes the execution of Psychtoolbox is resumed > \> only after > \> some random multi-millisecond delay has passed after buffer-swap, so the > \> stimulus onset timestamp can be possibly off by multiple milliseconds > \> from > \> the real stimulus onset time. This is unwanted timing noise, especially > \> if > \> the time stamp is to be used for either computing stimulus onset time for > \> future stimuli, or for synchronizing Psychtoolbox execution with other > \> stimulus generators or acquisition hardware. > \> > \> On Microsoft Windows 2000 and later, there is experimental support for > \> beamposition queries. This support is only enabled on single display > \> setups > \> and multi-display setups which are configured to appear to Psychtoolbox > \> as > \> single-display setups, i.e., one "virtual" primary monitor which consists > \> of multiple real displays in horizontal spanning mode. We use this > \> mechanism > \> to get high precision time stamps as the ones described below for > \> MacOS-X. > \> > \> On GNU/Linux, timing precision even in non-realtime scheduling mode is > \> far > \> superior to all other operating systems, yielding a timing jitter of less > \> than 100 microseconds under normal operating conditions. For special > \> needs, > \> there exist multiple methods of improving timing down to microsecond > \> level, > \> although some of time require some advanced programming skills. If > \> Psychtoolbox runs on an ATI graphics card of the X1000 series or HD xxxx > \> series and Matlab/Octave is run with superuser privileges, Psychtoolbox > \> will also utilize beamposition queries for even better timing precision. > \> On other graphics cards, this is not yet supported. > \> > \> On MacOS-X, whose timing accuracy is somewhere between Linux and Windows, > \> and luckily closer to Linux timing than to Windows timing, we use > \> beamposition > \> queries to improve accuracy of our timestamps, either with the native > \> support > \> on PowerPC computers and IntelMacs with NVidia or Intel graphics, or > \> with the > \> help of the PsychtoolboxKernelDriver (see help PsychtoolboxKernelDriver) > \> on > \> cards from ATI. An alternative mechanism, based on vertical blank > \> interrupts, is implemented on OS/X, should the beamposition mechanism > \> malfunction or become unavailable. > \> > \> This is how beamposition queries are used: > \> > \> When taking the system timestamp, we also query the current rasterbeam > \> position. > \> From the known height of the display (in scanlines, including height of > \> VBL), > \> and the known refresh interval of our display, we can translate the > \> current > \> beam position into "elapsed time since start of VBL == elapsed time since > \> double buffer swap". By subtracting this elapsed time value from our > \> system > \> timestamp, we get a corrected timestamp - the real system time of double > \> buffer > \> swap == start of VBL == aka stimulus onset. This allows for very > \> accurate timestamps, > \> despite possible non-deterministic multi-millisecond timing jitter. > \> Psychtoolbox > \> goes through great pains during startup to double-check that all required > \> calibration values and mechanisms are accurate and working properly. > \> You can assess the accuracy of all returned timestamps by use of the > \> script > \> VBLSyncTest. A visual correctness test is provided by > \> PerceptualVBLSyncTest. > \> PTB also performs continuous runtime checking to detect possible problems > \> caused by defective graphics card drivers. > \> > \> In case that beamposition queries should not work properly or are not > \> supported, > \> PTB will use different fallback strategies: > \> > \> On Microsoft Windows, only a normal - possibly noisy - timestamp is > \> taken. > \> > \> On MacOS-X, PTB tries to get low-level access to the kernel interrupt > \> handlers > \> for the VBL interrupts and uses its values for timestamping the time of > \> buffer- > \> swap. This method is slightly less accurate and robust than the > \> bemposition method, > \> but should be still suitable for most applications. If the kernel-level > \> queries should > \> fail as well, PTB falls back to pure timestamping without any correction. > \> > \> The behaviour of PTB can be controlled by the command: > \> Screen('Preference', 'VBLTimestampingMode', mode); where mode can be one > \> of the > \> following: > \> > \> -1 = Disable all cleverness, take noisy timestamps. This is the behaviour > \> you'd get from any other psychophysics toolkit, as far as we know. > \> 0 = Disable kernel-level fallback method (on OS-X), use either > \> beamposition > \> or noisy stamps if beamposition is unavailable. > \> 1 = Use beamposition. Should it fail, switch to use of kernel-level > \> interrupt > \> timestamps. If that fails as well or is unavailable, use noisy > \> stamps. > \> 2 = Use beamposition, but cross-check with kernel-level timestamps. > \> Use noisy stamps if beamposition mode fails. This is for the > \> paranoid > \> to check proper functioning. > \> 3 = Always use kernel-level timestamping, fall back to noisy stamps if > \> it fails. > \> 4 = Use OpenML OML\_sync\_control extension for high-precision > \> timestamping on > \> supported system configuration. This is currently a Linux only > \> feature on > \> some specific systems. It is considered experimental for now. > \> > \> The default on OS-X, Linux and Windows with single display setups is > \> "1". On Windows in > \> explicit multi-display mode, we default to "-1" ie. noisy timestamps if > \> you > \> are running Psychtoolbox under a Matlab version older than R2007a, as > \> the current > \> beamposition mechanism is not capable of supporting multi-display setups > \> due to some limitations imposed by old Matlab versions. On modern > \> Matlab's or Octave, the accurate mode "1" is used as well. On Linux and > \> OS/X > \> the accurate mode "1" is also used on multi-display setups. > \> > \> If the beampos query test fails, you will see some warning message about > \> "SYNCHRONIZATION TROUBLE" in the Matlab/Octave command window or other > \> error messages, as diagnostics is performed at various stages of setup > \> and operation. > \> > \> There are two possible causes for failure: > \> > \> 1. System overload: Too many other applications are running in parallel > \> to > \> Psychtoolbox, introducing severe timing noise into the calibration and > \> test loop. > \> See 'help SyncTrouble' on what to do. This happens rather seldomly. > \> > \> 2. Driver bug: Not much you can do, except submit a bug report to Apple > \> or Microsoft > \> for your specific hardware + software setup. This is by far the most > \> common cause of failure. Psychtoolbox tries to enable work-arounds for > \> some common problems if possible. Usually you should update your graphics > \> card driver to see if that resolves the problems. > \> > \> Note: As of Spring/Summer 2008, many graphics cards + driver combos from > \> ATI and NVidia on WindowsXP have bugs which cause beamposition queries to > \> fail in a peculiar way. If PTB detects that failure case, it will enable > \> some workaround to keep the mechanism going at slightly reduced accuracy: > \> Timestamps will still be mostly jitter-free and consistent, so they are > \> fully useable for timestamping, timing checks and as a basis for timed > \> stimulus presentation and animation. However, all returned timestamps > \> will contain a constant bias wrt. the real stimulus onset time of > \> somewhere between 20 microseconds and 1.5 milliseconds, depending on your > \> display settings, because Psychtoolbox can't determine the total height > \> of your display in scanlines (including the invisible VBL interval) > \> anymore. Exact height is important for spot-on timestamps. Psychtoolbox > \> uses some safe, conservative value for its internal computations, so > \> results will be consistent and useable, but contain a small constant > \> offset. > \> > \> In some rare cases, PTB's automatic test fails to detect the bug and > \> doesn't enable the workaround by itself. You can manually enable the > \> workaround if you want by adding the setting 4096 > \> (kPsychUseBeampositionQueryWorkaround) to the value x passed via: > \> Screen('Preference', 'ConserveVRAM', x); > \> > \> Just insert this command at the top of your scripts before any other > \> Screen() commands. 'x' must be at least 4096 or the sum of 4096 and any > \> other values you may want to pass with that command. See "help > \> ConserveVRAMSettings" for other workarounds that you can enable manually > \> if needed. > \> > \> If you want to get rid of that small offset, e.g., because you need to > \> synchronize with other modalities or stimulation/recording equipment at > \> sub-millisecond precisison, then you can try to figure out the real > \> height of the display yourself and tell Psychtoolbox about the true value > \> before calling Screen('OpenWindow'). > \> > \> Once you know the real height, e.g., VTOTAL, you'd call this function: > \> Screen('Preference', 'VBLEndlineOverride', VTOTAL); > \> > \> How to find out about VTOTAL? One way is to search the display control > \> panel on Windows for some area with "Advanced Timing" or "Custom Timing" > \> settings. The shareware utility "PowerStrip" > \> ([http://www.entechtaiwan.com/util/ps.shtm)](http://www.entechtaiwan.com/util/ps.shtm)) > \> also allows to change and display these parameters in the Advanced Timing > \> -\> Vertical Geometry -\> "Total" field. > \> > \> Accuracy of beamposition method: > \> > \> Cross-checking of beamposition timestamps and kernel-level timestamps on > \> a single > \> display PowerPC G5 1.6 Ghz under OS-X 10.4.8 with NVidia GeforceFX-5200 > \> showed an > \> accuracy of beamposition timestamping of better than 100 microseconds, > \> with a maximum > \> deviation between the different methods of less than 200 microseconds. > \> > \> Initial checking on two Window PC's (Dell Inspiron 8000 Laptop, Geforce > \> 2Go, Windows 2000, > \> and some 3.2 Ghz Pentium-4 with NVidia Geforce 7800 GTX) shows a > \> precision of about > \> 30 microseconds. No further testing on Windows has been performed yet by > \> us, but multiple users performed similar testing procedures on their > \> setups and confirmed the high accuracy and reliability for various MacOSX > \> and Windows setups. > \> > \> Also check the FAQ section of [http://www.psychtoolbox.org](http://www.psychtoolbox.org) for latest > \> infos. > \> > \> (end of help BeampositionQueries output) > \> > \> > \> note that i'm not quite sure how to update my graphics driver, but the app > \> store indicates my system software is up-to-date. is there anything else i > \> should check, or can i just ignore the WARNING and assume that > \> synchronisation is really fine? > \> j > \> -- > \> Joshua A. Solomon > \> [http://www.staff.city.ac.uk/~solomon](http://www.staff.city.ac.uk/~solomon) > \> ---
**Author:** ![smgxjas](https://avatars.discourse-cdn.com/v4/letter/s/e9a140/32.png) [@smgxjas](https://psychtoolbox.discourse.group/u/smgxjas)\ **Post date:** [January 5, 2013, 3:37pm UTC](https://psychtoolbox.discourse.group/t/installation-probs/375/5 "2013-01-05T15:37:13Z")
hi mario maybe you've fixed it. (thanks!) > On 02/01/2013 14:23, "Mario" \<[mario.kleiner@...](mailto:mario.kleiner@...)\> wrote: > > > \> > \>Is this a MacBookPro Retina? > > yes. > > \>What is its maximum resolution? > > the NVIDIA specs say 2880 X 1800 > > > \>Is the display resolution set to maximum or something lower? > > "best for Retina," which i assume is the maximum > > \>If you run BeampositionTest.m, how do the plots look like? > > here: > [http://www.staff.city.ac.uk/~solomon/MATLABScreenSnapz001.png](http://www.staff.city.ac.uk/~solomon/MATLABScreenSnapz001.png) > > \>The proper way to solve it, assuming it is the OSX graphics driver bug i > \>suspect it is, would be to install the PsychtoolboxKernelDriver ("help > \>PsychtoolboxKernelDriver") on your machine, and then force ptb to use it > \>in each session, by adding a: > \>v = bitor(2^16, Screen('Preference','ConserveVRAM')); > \>Screen('Preference','ConserveVRAM', v); > \>... to the top of each of your scripts > > done. > > \>the output of Screen('Computer') > > now says: > ans = > > macintosh: 0 > windows: 0 > osx: 1 > linux: 0 > kern: [1x1 struct] > hw: [1x1 struct] > processUserLongName: 'Joshua A. Solomon' > processUserShortName: 'js' > consoleUserName: 'js' > machineName: 'Solomon's Retina' > localHostName: 'Solomons-Retina' > location: '/Sets/0' > system: 'Mac OS 10.8.2' > gstreamer: 1 > > > \>\>\>\> DriftDemo6 > > this now seems to work (i.e. no exclamation point). output is > > PTB-INFO: This is Psychtoolbox-3 for Apple OS X, under Matlab 64-Bit > (Version 3.0.10 - Build date: Oct 29 2012). > 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: Broken Apple OS/X 10.7 or later detected: Using CoreVideo > timestamping instead of precise vbl-irq timestamping. > > > PTB-INFO: OpenGL-Renderer is NVIDIA Corporation :: NVIDIA GeForce GT 650M > OpenGL Engine :: 2.1 NVIDIA-8.6.22 > PTB-INFO: Renderer has 1024 MB of VRAM and a maximum 991 MB of texture > memory. > PTB-INFO: VBL startline = 900 , VBL Endline = -1 > PTB-INFO: Beamposition queries unsupported on this system. Will try to use > kernel-level vbl interrupts as fallback. > PTB-INFO: Measured monitor refresh interval from VBLsync = 16.691964 ms > [59.909068 Hz]. (297 valid samples taken, stddev=0.645714 ms.) > PTB-INFO: Small deviations between reported values are normal and no > reason to worry. > PTB-INFO: Support for fast OffscreenWindows enabled. > Building a fragment shader:Reading shader from file > /Applications/Psychtoolbox/PsychOpenGL/PsychGLSLShaders/SeparateAlphaTextur > eShader.frag.txt ... > Building a vertex shader:Reading shader from file > /Applications/Psychtoolbox/PsychOpenGL/PsychGLSLShaders/SeparateAlphaTextur > eShader.vert.txt ... > > > INFO: PTB's Screen('Flip', 10) command seems to have missed the requested > stimulus presentation deadline > INFO: a total of 52 times out of a total of 52 flips during this session. > > INFO: This number is fairly accurate (and indicative of real timing > problems in your own code or your system) > INFO: if you provided requested stimulus onset times with the 'when' > argument of Screen('Flip', window [, when]); > INFO: If you called Screen('Flip', window); without the 'when' argument, > this count is more of a ''mild'' indicator > INFO: of timing behaviour than a hard reliable measurement. Large numbers > may indicate problems and should at least > INFO: deserve your closer attention. Cfe. 'help SyncTrouble', the FAQ > section at www.psychtoolbox.org and the > INFO: examples in the PDF presentation in > PsychDocumentation/Psychtoolbox3-Slides.pdf for more info and timing tips. > > > j > -- > Joshua A. Solomon > [http://www.staff.city.ac.uk/~solomon](http://www.staff.city.ac.uk/~solomon) ---
**Author:** ![smgxjas](https://avatars.discourse-cdn.com/v4/letter/s/e9a140/32.png) [@smgxjas](https://psychtoolbox.discourse.group/u/smgxjas)\ **Post date:** [January 8, 2013, 7:47pm UTC](https://psychtoolbox.discourse.group/t/installation-probs/375/6 "2013-01-08T19:47:24Z")
On 08/01/2013 19:35, "Mario" \<[mario.kleiner@...](mailto:mario.kleiner@...)\> wrote: > \> > \>Yep, it now sort-of works. Can you give me the output at Screen verbosity > \>10? sure: screenid = 0 PTB-DEBUG: PsychGetScreenDepths(): mode 0 : w x h = 1440 x 900, fps = 0, depths = 16 PTB-DEBUG: PsychGetScreenDepths(): mode 1 : w x h = 1440 x 900, fps = 0, depths = 32 PTB-DEBUG: PsychGetScreenDepths(): mode 2 : w x h = 720 x 450, fps = 0, depths = 32 PTB-DEBUG: PsychGetScreenDepths(): mode 3 : w x h = 720 x 450, fps = 0, depths = 32 PTB-DEBUG: PsychGetScreenDepths(): mode 4 : w x h = 1920 x 1200, fps = 0, depths = 32 PTB-DEBUG: PsychGetScreenDepths(): mode 5 : w x h = 1920 x 1200, fps = 0, depths = 32 PTB-DEBUG: PsychGetScreenDepths(): mode 6 : w x h = 1680 x 1050, fps = 0, depths = 32 PTB-DEBUG: PsychGetScreenDepths(): mode 7 : w x h = 1680 x 1050, fps = 0, depths = 32 PTB-DEBUG: PsychGetScreenDepths(): mode 8 : w x h = 1280 x 800, fps = 0, depths = 32 PTB-DEBUG: PsychGetScreenDepths(): mode 9 : w x h = 1280 x 800, fps = 0, depths = 32 PTB-DEBUG: PsychGetScreenDepths(): mode 10 : w x h = 1024 x 640, fps = 0, depths = 32 PTB-DEBUG: PsychGetScreenDepths(): mode 11 : w x h = 1024 x 640, fps = 0, depths = 32 PTB-DEBUG: PsychGetScreenDepths(): mode 12 : w x h = 840 x 525, fps = 0, depths = 32 PTB-DEBUG: PsychGetScreenDepths(): mode 13 : w x h = 840 x 525, fps = 0, depths = 32 PTB-DEBUG: PsychGetScreenDepths(): mode 14 : w x h = 2880 x 1800, fps = 0, depths = 32 PTB-DEBUG: PsychGetScreenDepths(): mode 15 : w x h = 2880 x 1800, fps = 0, depths = 32 PTB-DEBUG: PsychGetScreenDepths(): mode 16 : w x h = 1440 x 900, fps = 0, depths = 16 PTB-DEBUG: PsychGetScreenDepths(): mode 17 : w x h = 1440 x 900, fps = 0, depths = 32 PTB-DEBUG: PsychGetScreenDepths(): mode 18 : w x h = 2560 x 1600, fps = 0, depths = 32 PTB-DEBUG: PsychGetScreenDepths(): mode 19 : w x h = 2560 x 1600, fps = 0, depths = 32 PTB-DEBUG: PsychGetScreenDepths(): mode 20 : w x h = 2048 x 1280, fps = 0, depths = 32 PTB-DEBUG: PsychGetScreenDepths(): mode 21 : w x h = 2048 x 1280, fps = 0, depths = 32 PTB-DEBUG: PsychGetScreenDepths(): mode 22 : w x h = 1024 x 768, fps = 0, depths = 32 PTB-DEBUG: PsychGetScreenDepths(): mode 23 : w x h = 1024 x 768, fps = 0, depths = 32 PTB-DEBUG: PsychGetScreenDepths(): mode 24 : w x h = 800 x 600, fps = 0, depths = 32 PTB-DEBUG: PsychGetScreenDepths(): mode 25 : w x h = 800 x 600, fps = 0, depths = 32 PTB-DEBUG: PsychGetScreenDepths(): mode 26 : w x h = 640 x 480, fps = 0, depths = 32 PTB-DEBUG: PsychGetScreenDepths(): mode 27 : w x h = 640 x 480, fps = 0, depths = 32 PTB-DEBUG: PsychGetScreenDepths(): mode 28 : w x h = 1680 x 1050, fps = 0, depths = 32 PTB-DEBUG: PsychGetScreenDepths(): mode 29 : w x h = 1680 x 1050, fps = 0, depths = 32 PTB-DEBUG: PsychGetScreenDepths(): mode 30 : w x h = 1280 x 800, fps = 0, depths = 32 PTB-DEBUG: PsychGetScreenDepths(): mode 31 : w x h = 1280 x 800, fps = 0, depths = 32 PTB-DEBUG: In PsychCaptureScreen(): After display capture for screen 0 (Old CGDisplayId 0x4280380). Reenumerating all displays... PTB-DEBUG: In PsychCaptureScreen(): After display capture for screen 0 (New CGDisplayId 0x4280380). Reenumeration done. PTB-INFO: This is Psychtoolbox-3 for Apple OS X, under Matlab 64-Bit (Version 3.0.10 - Build date: Jan 7 2013). 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: Using CGL for fullscreen onscreen window creation... PTB-INFO: Using GLEW version 1.5.3 for automatic detection of OpenGL extensions... PTB-INFO: Connection to kernel-level vbl handler established (shmem = 0x162000000). PTB-INFO: Broken Apple OS/X 10.7 or later detected: Using CoreVideo timestamping instead of precise vbl-irq timestamping. PTB-INFO: CVDisplayLink for screen 0 created to work around the brokenness of Apple Mac OS/X 10.7 and later: PTB-INFO: Video refresh interval as measured by CoreVideo display link: 16.669370 msecs. PTB-INFO: Video display output delay as reported by CoreVideo display link: nan msecs. PTB-DEBUG: PPM file magic is P6 -\> Ok # CREATOR: GIMP PNM Filter Version 1.1 PTB-DEBUG: Recognized splash image of 432 x 89 pixels, maxlevel 255. Loading... OpenGL-Extensions are: GL\_ARB\_color\_buffer\_float GL\_ARB\_depth\_buffer\_float GL\_ARB\_depth\_clamp GL\_ARB\_depth\_texture GL\_ARB\_draw\_buffers GL\_ARB\_draw\_elements\_base\_vertex GL\_ARB\_draw\_instanced GL\_ARB\_fragment\_program GL\_ARB\_fragment\_program\_shadow GL\_ARB\_fragment\_shader GL\_ARB\_framebuffer\_object GL\_ARB\_framebuffer\_sRGB GL\_ARB\_half\_float\_pixel GL\_ARB\_half\_float\_vertex GL\_ARB\_imaging GL\_ARB\_instanced\_arrays GL\_ARB\_multisample GL\_ARB\_multitexture GL\_ARB\_occlusion\_query GL\_ARB\_pixel\_buffer\_object GL\_ARB\_point\_parameters GL\_ARB\_point\_sprite GL\_ARB\_provoking\_vertex GL\_ARB\_seamless\_cube\_map GL\_ARB\_shader\_objects GL\_ARB\_shader\_texture\_lod GL\_ARB\_shading\_language\_100 GL\_ARB\_shadow GL\_ARB\_sync GL\_ARB\_texture\_border\_clamp GL\_ARB\_texture\_compression GL\_ARB\_texture\_compression\_rgtc GL\_ARB\_texture\_cube\_map GL\_ARB\_texture\_env\_add GL\_ARB\_texture\_env\_combine GL\_ARB\_texture\_env\_crossbar GL\_ARB\_texture\_env\_dot3 GL\_ARB\_texture\_float GL\_ARB\_texture\_mirrored\_repeat GL\_ARB\_texture\_non\_power\_of\_two GL\_ARB\_texture\_rectangle GL\_ARB\_texture\_rg GL\_ARB\_transpose\_matrix GL\_ARB\_vertex\_array\_bgra GL\_ARB\_vertex\_blend GL\_ARB\_vertex\_buffer\_object GL\_ARB\_vertex\_program GL\_ARB\_vertex\_shader GL\_ARB\_window\_pos GL\_EXT\_abgr GL\_EXT\_bgra GL\_EXT\_bindable\_uniform GL\_EXT\_blend\_color GL\_EXT\_blend\_equation\_separate GL\_EXT\_blend\_func\_separate GL\_EXT\_blend\_minmax GL\_EXT\_blend\_subtract GL\_EXT\_clip\_volume\_hint GL\_EXT\_compiled\_vertex\_array GL\_EXT\_depth\_bounds\_test GL\_EXT\_draw\_buffers2 GL\_EXT\_draw\_range\_elements GL\_EXT\_fog\_coord GL\_EXT\_framebuffer\_blit GL\_EXT\_framebuffer\_multisample GL\_EXT\_framebuffer\_multisample\_blit\_scaled GL\_EXT\_framebuffer\_object GL\_EXT\_framebuffer\_sRGB GL\_EXT\_geometry\_shader4 GL\_EXT\_gpu\_program\_parameters GL\_EXT\_gpu\_shader4 GL\_EXT\_multi\_draw\_arrays GL\_EXT\_packed\_depth\_stencil GL\_EXT\_packed\_float GL\_EXT\_provoking\_vertex GL\_EXT\_rescale\_normal GL\_EXT\_secondary\_color GL\_EXT\_shadow\_funcs GL\_EXT\_stencil\_two\_side GL\_EXT\_stencil\_wrap GL\_EXT\_texture\_array GL\_EXT\_texture\_compression\_dxt1 GL\_EXT\_texture\_compression\_s3tc GL\_EXT\_texture\_env\_add GL\_EXT\_texture\_filter\_anisotropic GL\_EXT\_texture\_integer GL\_EXT\_texture\_lod\_bias GL\_EXT\_texture\_mirror\_clamp GL\_EXT\_texture\_rectangle GL\_EXT\_texture\_shared\_exponent GL\_EXT\_texture\_sRGB GL\_EXT\_texture\_sRGB\_decode GL\_EXT\_timer\_query GL\_EXT\_transform\_feedback GL\_EXT\_vertex\_array\_bgra GL\_APPLE\_aux\_depth\_stencil GL\_APPLE\_client\_storage GL\_APPLE\_element\_array GL\_APPLE\_fence GL\_APPLE\_float\_pixels GL\_APPLE\_flush\_buffer\_range GL\_APPLE\_flush\_render GL\_APPLE\_object\_purgeable GL\_APPLE\_packed\_pixels GL\_APPLE\_pixel\_buffer GL\_APPLE\_rgb\_422 GL\_APPLE\_row\_bytes GL\_APPLE\_specular\_vector GL\_APPLE\_texture\_range GL\_APPLE\_transform\_hint GL\_APPLE\_vertex\_array\_object GL\_APPLE\_vertex\_array\_range GL\_APPLE\_vertex\_point\_size GL\_APPLE\_vertex\_program\_evaluators GL\_APPLE\_ycbcr\_422 GL\_ATI\_separate\_stencil GL\_ATI\_texture\_env\_combine3 GL\_ATI\_texture\_float GL\_ATI\_texture\_mirror\_once GL\_IBM\_rasterpos\_clip GL\_NV\_blend\_square GL\_NV\_conditional\_render GL\_NV\_depth\_clamp GL\_NV\_fog\_distance GL\_NV\_fragment\_program\_option GL\_NV\_fragment\_program2 GL\_NV\_light\_max\_exponent GL\_NV\_multisample\_filter\_hint GL\_NV\_point\_sprite GL\_NV\_texgen\_reflection GL\_NV\_vertex\_program2\_option GL\_NV\_vertex\_program3 GL\_SGIS\_generate\_mipmap GL\_SGIS\_texture\_edge\_clamp GL\_SGIS\_texture\_lod PTB-DEBUG: Interrogating Low-level renderer capabilities for onscreen window with handle 10: Indicator variables: FBO's 1, ATI\_texture\_float 1, ARB\_texture\_float 1, Vendor NVIDIA Corporation, Renderer NVIDIA GeForce GT 650M OpenGL Engine. Indicator variables: maxcolorattachments = 8, maxrectangletexturesize = 16384, maxnativealuinstructions = 16384. GPU supports UYVY - YCrCb texture formats for optimized handling of video content. GPU supports non-power-of-two textures. Basic framebuffer objects with rectangle texture rendertargets supported --\> RGBA8 rendertargets with blending. Framebuffer objects support fast blitting between each other. Framebuffer objects support anti-aliasing via multisampling. Framebuffer objects support single-pass multisample resolve blits and image rescaling. Hardware supports floating point textures of 16bpc and 32bpc float format. Assuming NV30 core or later... Assuming NV40 core or later (maxcolattachments=8): Hardware supports floating point blending and filtering on 16bpc float format. Hardware also supports floating point framebuffers of 16bpc and 32bpc float format. Hardware supports full 32 bit floating point precision shading. Assuming G80 core or later (maxtexsize=16384): Hardware supports full floating point blending and filtering on 16bpc and 32bpc float format. No compiled in support for OpenML OML\_sync\_control extension. Using standard implementation. PTB-DEBUG: Interrogation done. PTB-DEBUG: glClear splash image top-left reference pixel: 255 255 255 PTB-INFO: Threshold Settings for successfull video refresh calibration are: maxStdDev = 1.000000 msecs, maxDeviation = 10.000000 %, minSamples = 50, maxDuration = 5.000000 secs. PTB-WARNING: Seems this window is displayed on a Retina-Display in scaled mode at a non-native resolution for the display. PTB-WARNING: Reliabiliy of visual stimulus onset timing in such a scaled mode is so far unknown, but may be severely degraded. PTB-WARNING: Stimulus onset timing and returned timestamps may be wrong, with no way for me to automatically detect this. PTB-DEBUG: Output of all acquired samples of calibration run follows: PTB-DEBUG: Sample 0: 0.000000 PTB-DEBUG: Sample 1: 0.016581 PTB-DEBUG: Sample 2: 0.017362 PTB-DEBUG: Sample 3: 0.016594 PTB-DEBUG: Sample 4: 0.016440 PTB-DEBUG: Sample 5: 0.016488 PTB-DEBUG: Sample 6: 0.016325 PTB-DEBUG: Sample 7: 0.017416 PTB-DEBUG: Sample 8: 0.016574 PTB-DEBUG: Sample 9: 0.016469 PTB-DEBUG: Sample 10: 0.016401 PTB-DEBUG: Sample 11: 0.016477 PTB-DEBUG: Sample 12: 0.017368 PTB-DEBUG: Sample 13: 0.016544 PTB-DEBUG: Sample 14: 0.016583 PTB-DEBUG: Sample 15: 0.016577 PTB-DEBUG: Sample 16: 0.016434 PTB-DEBUG: Sample 17: 0.016588 PTB-DEBUG: Sample 18: 0.016625 PTB-DEBUG: Sample 19: 0.017344 PTB-DEBUG: Sample 20: 0.016647 PTB-DEBUG: Sample 21: 0.016466 PTB-DEBUG: Sample 22: 0.016704 PTB-DEBUG: Sample 23: 0.016527 PTB-DEBUG: Sample 24: 0.016299 PTB-DEBUG: Sample 25: 0.017389 PTB-DEBUG: Sample 26: 0.016449 PTB-DEBUG: Sample 27: 0.016378 PTB-DEBUG: Sample 28: 0.017441 PTB-DEBUG: Sample 29: 0.016562 PTB-DEBUG: Sample 30: 0.016205 PTB-DEBUG: Sample 31: 0.016279 PTB-DEBUG: Sample 32: 0.017262 PTB-DEBUG: Sample 33: 0.016208 PTB-DEBUG: Sample 34: 0.017360 PTB-DEBUG: Sample 35: 0.016175 PTB-DEBUG: Sample 36: 0.016168 PTB-DEBUG: Sample 37: 0.017284 PTB-DEBUG: Sample 38: 0.017158 PTB-DEBUG: Sample 39: 0.016241 PTB-DEBUG: Sample 40: 0.016130 PTB-DEBUG: Sample 41: 0.017194 PTB-DEBUG: Sample 42: 0.016078 PTB-DEBUG: Sample 43: 0.017213 PTB-DEBUG: Sample 44: 0.016141 PTB-DEBUG: Sample 45: 0.017253 PTB-DEBUG: Sample 46: 0.016053 PTB-DEBUG: Sample 47: 0.017237 PTB-DEBUG: Sample 48: 0.016169 PTB-DEBUG: Sample 49: 0.017307 PTB-DEBUG: Sample 50: 0.016050 PTB-DEBUG: Sample 51: 0.017252 PTB-DEBUG: Sample 52: 0.016041 PTB-DEBUG: Sample 53: 0.017371 PTB-DEBUG: Sample 54: 0.016266 PTB-DEBUG: Sample 55: 0.017173 PTB-DEBUG: Sample 56: 0.016169 PTB-DEBUG: Sample 57: 0.017267 PTB-DEBUG: Sample 58: 0.016058 PTB-DEBUG: Sample 59: 0.017271 PTB-DEBUG: Sample 60: 0.016041 PTB-DEBUG: Sample 61: 0.017172 PTB-DEBUG: Sample 62: 0.015932 PTB-DEBUG: Sample 63: 0.017282 PTB-DEBUG: Sample 64: 0.016096 PTB-DEBUG: Sample 65: 0.017275 PTB-DEBUG: Sample 66: 0.017109 PTB-DEBUG: Sample 67: 0.016207 PTB-DEBUG: Sample 68: 0.015977 PTB-DEBUG: Sample 69: 0.017298 PTB-DEBUG: Sample 70: 0.016069 PTB-DEBUG: Sample 71: 0.017269 PTB-DEBUG: Sample 72: 0.015877 PTB-DEBUG: Sample 73: 0.017228 PTB-DEBUG: Sample 74: 0.016155 PTB-DEBUG: Sample 75: 0.017247 PTB-DEBUG: Sample 76: 0.016124 PTB-DEBUG: Sample 77: 0.017196 PTB-DEBUG: Sample 78: 0.017215 PTB-DEBUG: Sample 79: 0.016224 PTB-DEBUG: Sample 80: 0.016201 PTB-DEBUG: Sample 81: 0.017377 PTB-DEBUG: Sample 82: 0.016202 PTB-DEBUG: Sample 83: 0.017352 PTB-DEBUG: Sample 84: 0.016145 PTB-DEBUG: Sample 85: 0.015981 PTB-DEBUG: Sample 86: 0.016810 PTB-DEBUG: Sample 87: 0.017273 PTB-DEBUG: Sample 88: 0.016067 PTB-DEBUG: Sample 89: 0.017319 PTB-DEBUG: Sample 90: 0.016089 PTB-DEBUG: Sample 91: 0.017339 PTB-DEBUG: Sample 92: 0.016068 PTB-DEBUG: Sample 93: 0.017254 PTB-DEBUG: Sample 94: 0.016052 PTB-DEBUG: Sample 95: 0.017327 PTB-DEBUG: Sample 96: 0.016246 PTB-DEBUG: Sample 97: 0.017438 PTB-DEBUG: Sample 98: 0.016210 PTB-DEBUG: Sample 99: 0.016176 PTB-DEBUG: Sample 100: 0.017087 PTB-DEBUG: Sample 101: 0.016094 PTB-DEBUG: Sample 102: 0.017193 PTB-DEBUG: Sample 103: 0.016171 PTB-DEBUG: Sample 104: 0.017235 PTB-DEBUG: Sample 105: 0.016104 PTB-DEBUG: Sample 106: 0.017220 PTB-DEBUG: Sample 107: 0.016071 PTB-DEBUG: Sample 108: 0.017339 PTB-DEBUG: Sample 109: 0.016115 PTB-DEBUG: Sample 110: 0.017142 PTB-DEBUG: Sample 111: 0.016095 PTB-DEBUG: Sample 112: 0.017354 PTB-DEBUG: Sample 113: 0.016048 PTB-DEBUG: Sample 114: 0.017139 PTB-DEBUG: Sample 115: 0.016150 PTB-DEBUG: Sample 116: 0.016730 PTB-DEBUG: Sample 117: 0.017348 PTB-DEBUG: Sample 118: 0.016131 PTB-DEBUG: Sample 119: 0.017370 PTB-DEBUG: Sample 120: 0.016284 PTB-DEBUG: Sample 121: 0.016130 PTB-DEBUG: Sample 122: 0.017346 PTB-DEBUG: Sample 123: 0.015952 PTB-DEBUG: Sample 124: 0.017241 PTB-DEBUG: Sample 125: 0.016113 PTB-DEBUG: Sample 126: 0.017156 PTB-DEBUG: Sample 127: 0.017303 PTB-DEBUG: Sample 128: 0.015966 PTB-DEBUG: Sample 129: 0.017292 PTB-DEBUG: Sample 130: 0.016157 PTB-DEBUG: Sample 131: 0.017343 PTB-DEBUG: Sample 132: 0.016086 PTB-DEBUG: Sample 133: 0.016056 PTB-DEBUG: Sample 134: 0.017379 PTB-DEBUG: Sample 135: 0.016107 PTB-DEBUG: Sample 136: 0.017152 PTB-DEBUG: Sample 137: 0.016080 PTB-DEBUG: Sample 138: 0.017388 PTB-DEBUG: Sample 139: 0.016032 PTB-DEBUG: Sample 140: 0.017107 PTB-DEBUG: Sample 141: 0.016161 PTB-DEBUG: Sample 142: 0.017225 PTB-DEBUG: Sample 143: 0.016069 PTB-DEBUG: Sample 144: 0.017068 PTB-DEBUG: Sample 145: 0.017300 PTB-DEBUG: Sample 146: 0.016108 PTB-DEBUG: Sample 147: 0.017218 PTB-DEBUG: Sample 148: 0.016183 PTB-DEBUG: Sample 149: 0.017061 PTB-DEBUG: Sample 150: 0.015989 PTB-DEBUG: Sample 151: 0.017312 PTB-DEBUG: Sample 152: 0.016065 PTB-DEBUG: Sample 153: 0.017346 PTB-DEBUG: Sample 154: 0.016143 PTB-DEBUG: Sample 155: 0.017250 PTB-DEBUG: Sample 156: 0.016121 PTB-DEBUG: Sample 157: 0.017415 PTB-DEBUG: Sample 158: 0.016150 PTB-DEBUG: Sample 159: 0.016215 PTB-DEBUG: Sample 160: 0.017097 PTB-DEBUG: Sample 161: 0.016060 PTB-DEBUG: Sample 162: 0.017221 PTB-DEBUG: Sample 163: 0.016062 PTB-DEBUG: Sample 164: 0.017243 PTB-DEBUG: Sample 165: 0.016243 PTB-DEBUG: Sample 166: 0.017478 PTB-DEBUG: Sample 167: 0.016455 PTB-DEBUG: Sample 168: 0.016001 PTB-DEBUG: Sample 169: 0.017328 PTB-DEBUG: Sample 170: 0.016012 PTB-DEBUG: Sample 171: 0.017223 PTB-DEBUG: Sample 172: 0.016064 PTB-DEBUG: Sample 173: 0.017287 PTB-DEBUG: Sample 174: 0.016075 PTB-DEBUG: Sample 175: 0.017345 PTB-DEBUG: Sample 176: 0.016170 PTB-DEBUG: Sample 177: 0.017543 PTB-DEBUG: Sample 178: 0.016100 PTB-DEBUG: Sample 179: 0.017333 PTB-DEBUG: Sample 180: 0.016108 PTB-DEBUG: Sample 181: 0.017129 PTB-DEBUG: Sample 182: 0.016182 PTB-DEBUG: Sample 183: 0.017128 PTB-DEBUG: Sample 184: 0.016211 PTB-DEBUG: Sample 185: 0.016121 PTB-DEBUG: Sample 186: 0.017304 PTB-DEBUG: Sample 187: 0.016106 PTB-DEBUG: Sample 188: 0.017184 PTB-DEBUG: Sample 189: 0.016097 PTB-DEBUG: Sample 190: 0.017328 PTB-DEBUG: Sample 191: 0.016101 PTB-DEBUG: Sample 192: 0.016988 PTB-DEBUG: Sample 193: 0.016881 PTB-DEBUG: Sample 194: 0.016271 PTB-DEBUG: Sample 195: 0.017424 PTB-DEBUG: Sample 196: 0.016376 PTB-DEBUG: Sample 197: 0.016244 PTB-DEBUG: Sample 198: 0.017328 PTB-DEBUG: Sample 199: 0.016023 PTB-DEBUG: Sample 200: 0.017278 PTB-DEBUG: Sample 201: 0.016304 PTB-DEBUG: Sample 202: 0.016155 PTB-DEBUG: Sample 203: 0.017183 PTB-DEBUG: Sample 204: 0.016062 PTB-DEBUG: Sample 205: 0.017396 PTB-DEBUG: Sample 206: 0.016137 PTB-DEBUG: Sample 207: 0.017131 PTB-DEBUG: Sample 208: 0.016141 PTB-DEBUG: Sample 209: 0.017253 PTB-DEBUG: Sample 210: 0.016016 PTB-DEBUG: Sample 211: 0.017154 PTB-DEBUG: Sample 212: 0.017346 PTB-DEBUG: Sample 213: 0.016272 PTB-DEBUG: Sample 214: 0.015966 PTB-DEBUG: Sample 215: 0.017437 PTB-DEBUG: Sample 216: 0.016088 PTB-DEBUG: Sample 217: 0.017402 PTB-DEBUG: Sample 218: 0.015989 PTB-DEBUG: Sample 219: 0.017331 PTB-DEBUG: Sample 220: 0.016139 PTB-DEBUG: Sample 221: 0.017334 PTB-DEBUG: Sample 222: 0.016161 PTB-DEBUG: Sample 223: 0.017012 PTB-DEBUG: Sample 224: 0.016019 PTB-DEBUG: Sample 225: 0.017166 PTB-DEBUG: Sample 226: 0.016131 PTB-DEBUG: Sample 227: 0.017066 PTB-DEBUG: Sample 228: 0.016126 PTB-DEBUG: Sample 229: 0.017334 PTB-DEBUG: Sample 230: 0.015805 PTB-DEBUG: Sample 231: 0.017308 PTB-DEBUG: Sample 232: 0.016198 PTB-DEBUG: Sample 233: 0.017235 PTB-DEBUG: Sample 234: 0.015979 PTB-DEBUG: Sample 235: 0.017307 PTB-DEBUG: Sample 236: 0.017257 PTB-DEBUG: Sample 237: 0.016173 PTB-DEBUG: Sample 238: 0.016249 PTB-DEBUG: Sample 239: 0.017314 PTB-DEBUG: Sample 240: 0.016158 PTB-DEBUG: Sample 241: 0.017365 PTB-DEBUG: Sample 242: 0.016176 PTB-DEBUG: Sample 243: 0.016122 PTB-DEBUG: Sample 244: 0.017203 PTB-DEBUG: Sample 245: 0.016152 PTB-DEBUG: Sample 246: 0.017187 PTB-DEBUG: Sample 247: 0.016029 PTB-DEBUG: Sample 248: 0.017075 PTB-DEBUG: Sample 249: 0.017323 PTB-DEBUG: Sample 250: 0.016054 PTB-DEBUG: Sample 251: 0.017375 PTB-DEBUG: Sample 252: 0.016182 PTB-DEBUG: Sample 253: 0.017230 PTB-DEBUG: Sample 254: 0.016508 PTB-DEBUG: Sample 255: 0.016248 PTB-DEBUG: Sample 256: 0.017152 PTB-DEBUG: Sample 257: 0.016153 PTB-DEBUG: Sample 258: 0.017283 PTB-DEBUG: Sample 259: 0.016188 PTB-DEBUG: Sample 260: 0.016085 PTB-DEBUG: Sample 261: 0.017203 PTB-DEBUG: Sample 262: 0.017359 PTB-DEBUG: Sample 263: 0.016211 PTB-DEBUG: Sample 264: 0.016230 PTB-DEBUG: Sample 265: 0.017159 PTB-DEBUG: Sample 266: 0.016202 PTB-DEBUG: Sample 267: 0.017237 PTB-DEBUG: Sample 268: 0.016292 PTB-DEBUG: Sample 269: 0.016269 PTB-DEBUG: Sample 270: 0.017200 PTB-DEBUG: Sample 271: 0.016077 PTB-DEBUG: Sample 272: 0.017251 PTB-DEBUG: Sample 273: 0.016034 PTB-DEBUG: Sample 274: 0.017445 PTB-DEBUG: Sample 275: 0.016342 PTB-DEBUG: Sample 276: 0.016233 PTB-DEBUG: Sample 277: 0.017218 PTB-DEBUG: Sample 278: 0.017308 PTB-DEBUG: Sample 279: 0.016237 PTB-DEBUG: Sample 280: 0.016055 PTB-DEBUG: Sample 281: 0.017327 PTB-DEBUG: Sample 282: 0.016358 PTB-DEBUG: Sample 283: 0.017144 PTB-DEBUG: Sample 284: 0.016106 PTB-DEBUG: Sample 285: 0.017219 PTB-DEBUG: Sample 286: 0.016231 PTB-DEBUG: Sample 287: 0.017233 PTB-DEBUG: Sample 288: 0.016076 PTB-DEBUG: Sample 289: 0.017123 PTB-DEBUG: Sample 290: 0.015986 PTB-DEBUG: Sample 291: 0.017311 PTB-DEBUG: Sample 292: 0.016136 PTB-DEBUG: Sample 293: 0.017390 PTB-DEBUG: Sample 294: 0.016088 PTB-DEBUG: Sample 295: 0.017496 PTB-DEBUG: Sample 296: 0.015977 PTB-DEBUG: Sample 297: 0.016091 PTB-DEBUG: Sample 298: 0.017297 PTB-DEBUG: End of calibration data for this run... PTB-INFO: OpenGL-Renderer is NVIDIA Corporation :: NVIDIA GeForce GT 650M OpenGL Engine :: 2.1 NVIDIA-8.6.22 PTB-INFO: Renderer has 1024 MB of VRAM and a maximum 984 MB of texture memory. PTB-INFO: VBL startline = 1800 , VBL Endline = 1851 PTB-INFO: Measured monitor refresh interval from beamposition = 16.669320 ms [59.990448 Hz]. PTB-INFO: Will use beamposition query for accurate Flip time stamping. PTB-INFO: Measured monitor refresh interval from VBLsync = 16.670578 ms [59.985921 Hz]. (298 valid samples taken, stddev=0.556441 ms.) PTB-INFO: Small deviations between reported values are normal and no reason to worry. PTB-INFO: Support for fast OffscreenWindows enabled. PTB-DEBUG: Swaprequest too close to last swap vbl (0.000503 secs) or between forbidden scanline 1 and 50. Delaying... VBL timestamp deviation: precount=357 , postcount=358, delta = 1, postflip\_vbltimestamp = 32660.400034 - beampos\_vbltimestamp = 32660.398353 == Delta is = 0.001681 PTB-DEBUG: Swaprequest too close to last swap vbl (0.001018 secs) or between forbidden scanline 1 and 50. Delaying... VBL timestamp deviation: precount=358 , postcount=358, delta = 0, postflip\_vbltimestamp = 32660.400058 - beampos\_vbltimestamp = 32660.398355 == Delta is = 0.001704 PTB-ERROR: Screen('Flip'); beamposition timestamping computed an \*impossible stimulus onset value\* of 32660.398355 secs, which would indicate that PTB-ERROR: stimulus onset happened \*before\* it was actually requested! (Earliest theoretically possible 32660.400603 secs). PTB-ERROR: Some more diagnostic values (only for experts): rawTimestamp = 32660.414611, scanline = 1753 PTB-ERROR: Some more diagnostic values (only for experts): line\_pre\_swaprequest = 198, line\_post\_swaprequest = 241, time\_post\_swaprequest = 32660.400992 PTB-ERROR: Some more diagnostic values (only for experts): preflip\_vblcount = 358, preflip\_vbltimestamp = 32660.400034 PTB-ERROR: Some more diagnostic values (only for experts): postflip\_vblcount = 358, postflip\_vbltimestamp = 32660.400058, vbltimestampquery\_retrycount = 0 PTB-ERROR: The most likely cause of this error (based on cross-check with kernel-level timestamping) is: PTB-ERROR: Something may be broken in your systems beamposition timestamping. Read 'help SyncTrouble' ! PTB-ERROR: For the remainder of this session, i've switched to kernel based timestamping as a backup method. PTB-ERROR: This method is slightly less accurate and higher overhead but should be similarly robust. PTB-ERROR: A less likely cause could be that Synchronization of stimulus onset (buffer swap) to the PTB-ERROR: vertical blank interval VBL is not working properly. PTB-ERROR: Please run the script PerceptualVBLSyncTest to check this. With non-working sync to VBL, all stimulus timing PTB-ERROR: becomes quite futile. tel = 0.0377 PTB-DEBUG: In ScreenCloseAllWindows(): Destroying window 0 PTB-DEBUG: In PsychReleaseScreen(): After display release for screen 0 (Old CGDisplayId 0x4280380). Reenumerating all displays... PTB-DEBUG: In PsychReleaseScreen(): After display release for screen 0 (New CGDisplayId 0x4280380). Reenumeration done. OwnerPID: 161 WindowLevel: 25 (ShieldingWindow 2147483629) WindowOwnerName: SystemUIServer OwnerPID: 161 WindowLevel: 25 (ShieldingWindow 2147483629) WindowOwnerName: SystemUIServer OwnerPID: 161 WindowLevel: 25 (ShieldingWindow 2147483629) WindowOwnerName: SystemUIServer OwnerPID: 573 WindowLevel: 25 (ShieldingWindow 2147483629) WindowOwnerName: Vuze OwnerPID: 528 WindowLevel: 25 (ShieldingWindow 2147483629) WindowOwnerName: Skype OwnerPID: 231 WindowLevel: 25 (ShieldingWindow 2147483629) WindowOwnerName: Dropbox OwnerPID: 212 WindowLevel: 25 (ShieldingWindow 2147483629) WindowOwnerName: Growl OwnerPID: 197 WindowLevel: 25 (ShieldingWindow 2147483629) WindowOwnerName: gfxCardStatus OwnerPID: 177 WindowLevel: 25 (ShieldingWindow 2147483629) WindowOwnerName: Notification Center OwnerPID: 98 WindowLevel: 24 (ShieldingWindow 2147483629) WindowName: Menubar WindowOwnerName: Window Server OwnerPID: 160 WindowLevel: 20 (ShieldingWindow 2147483629) WindowName: Dock WindowOwnerName: Dock OwnerPID: 160 WindowLevel: 19 (ShieldingWindow 2147483629) WindowName: Magic Mirror WindowOwnerName: Dock OwnerPID: 2519 WindowLevel: 0 (ShieldingWindow 2147483629) WindowName: MATLAB R2012b WindowOwnerName: MATLAB TARGETWINDOWNAME: 'MATLAB R2012b' with pid 2519. PTB-DEBUG: In PsychCaptureScreen(): After display capture for screen 0 (Old CGDisplayId 0x4280380). Reenumerating all displays... PTB-DEBUG: In PsychCaptureScreen(): After display capture for screen 0 (New CGDisplayId 0x4280380). Reenumeration done. PTB-INFO: Releasing shared memory mapping for screen 0. PTB-INFO: Releasing CVDisplayLink for screen 0. PTB-DEBUG: In PsychReleaseScreen(): After display release for screen 0 (Old CGDisplayId 0x4280380). Reenumerating all displays... PTB-DEBUG: In PsychReleaseScreen(): After display release for screen 0 (New CGDisplayId 0x4280380). Reenumeration done. OwnerPID: 161 WindowLevel: 25 (ShieldingWindow 2147483629) WindowOwnerName: SystemUIServer OwnerPID: 161 WindowLevel: 25 (ShieldingWindow 2147483629) WindowOwnerName: SystemUIServer OwnerPID: 161 WindowLevel: 25 (ShieldingWindow 2147483629) WindowOwnerName: SystemUIServer OwnerPID: 573 WindowLevel: 25 (ShieldingWindow 2147483629) WindowOwnerName: Vuze OwnerPID: 528 WindowLevel: 25 (ShieldingWindow 2147483629) WindowOwnerName: Skype OwnerPID: 231 WindowLevel: 25 (ShieldingWindow 2147483629) WindowOwnerName: Dropbox OwnerPID: 212 WindowLevel: 25 (ShieldingWindow 2147483629) WindowOwnerName: Growl OwnerPID: 197 WindowLevel: 25 (ShieldingWindow 2147483629) WindowOwnerName: gfxCardStatus OwnerPID: 177 WindowLevel: 25 (ShieldingWindow 2147483629) WindowOwnerName: Notification Center OwnerPID: 98 WindowLevel: 24 (ShieldingWindow 2147483629) WindowName: Menubar WindowOwnerName: Window Server OwnerPID: 160 WindowLevel: 20 (ShieldingWindow 2147483629) WindowName: Dock WindowOwnerName: Dock OwnerPID: 160 WindowLevel: 19 (ShieldingWindow 2147483629) WindowName: Magic Mirror WindowOwnerName: Dock OwnerPID: 2519 WindowLevel: 0 (ShieldingWindow 2147483629) WindowName: MATLAB R2012b WindowOwnerName: MATLAB TARGETWINDOWNAME: 'MATLAB R2012b' with pid 2519. > \>Ian also helps testing, he has access to a Datapixx, so we should be able > \>to figure out which is which in the end by comparing our timestamps > \>against the hardware timestamps. FWIW I'll be at the IoO tomorrow. (Are you still there, Ian?) I'll bring along my MacBook.