PTB BETA update "Spooling up the spinner!"

1

Psychtoolbox 3.0.14 beta release "Spooling up the spinner"

This release contains the accumulated work of 4 months, 200 separate improvements in 176 files, changing about 27000 lines of code. Major work was done under the hood for Linux improvements and prep work for VR HMD support improvements. Apart from those, the following user visible fixes, improvements and new features have been added:

Linux:

  • Improved hybrid graphics laptop support: Detail work and improved setup documentation for hybrid graphics with the open-source drivers (Intel + AMD, Intel + NVidia), and verified that NVidia Optimus (Intel + NVidia) also works ok with NVidia proprietary drivers, as tested on Ubuntu 17.04 "Zesty Zappus". Add extra setup instructions specifically for NVidia + Ubuntu 17.04. Tested on two separate Optimus laptops, a Lenovo Ideapad Z50-70, and a Razer Blade 2016 with GeForce Pascal.

  • Improved compatibility with amdgpu-pro hybrid graphics driver, for the very few cases where that driver is beneficial over the standard AMD open-source drivers, e.g., certain 144/165/240 Hz refresh rate displays.

  • Improved 11 bpc / 16 bpc native framebuffer support for AMD gpu's, and better setup instructions.

  • NVidia NVision 3d stereo emitter support for NVidia stereo goggles on regular consumer class GeForce gpu's, AMD gpu's and Intel gpu's should now work with more emitter models, especially - as tested - with some NVision-2 emitters, whereas before only original NVision-1 emitters worked.

  • GetMouseWheel() now also works on Linux.

  • Improve GetMouse() coordinate handling on multi-x-screen.

  • Make PR-670 photometer work out of the box on Linux by adding workarounds for that devices broken firmware. Note: PR-670 remains broken on OSX 10.11, but seems to work on OSX 10.12.

  • Improve default keyboard selection if exotic or broken keyboard like devices are connected.

  • Various improvements, bug fixes, too many to mention.

MS-Windows:

  • Screen(): Disable the magic "@" master abort key.

  • Better support for compose/compound/dead keys handling for GetChar / KbEventGet by Diederick.

  • PsychRTBox: Fix box serial port probing for Octave on Windows. Although Xiangrui Li found an even better solution, which is not part of this update yet.

  • Fix Optical() brokeness due to compatibility bugs introduced by MS into Windows-7. Credit: Andreas Widmann.

OSX:

  • help PsychtoolboxKernelDriver: Update setup instructions / help text for OSX 10.11+.

  • Document 10/11 bpc framebuffer mode behaviour on OSX 10.11/10.12, improve setup code. Thanks to Denis Pelli and Hoermet Yiltiz for testing on their machines.

  • Some fixes for MacBookPro 2016's brokeness.

All systems:

  • New function Screen('ConstrainCursor'); for Linux/X11 and MS-Windows: Allows to constrain cursor movements to subareas of an onscreen window. Not supportable on OSX due to lack of OS facilities.

  • DrawFormattedText: Optionally return per-word bounding boxes to define AOI's, e.g., for text perception + eye tracking studies.

  • Brand-new DrawFormattedText2() function and DrawFormattedText2Demo by Diederick Niehorster. More flexible in its formatting and text transformation options than DrawFormattedText. This is considered beta quality for now, bugs may linger in this large new piece of code. I added the ability to return per-word bounding boxes, like in DrawFormattedText, but that code has the limitation that it doesn't yet work with complex compound transforms.

  • VideoIPWebcamCaptureDemo: Add sample mode for screencasting. Setup code and example gst-launch lines for live screen-casting from Linux X11 (tested) or Windows (untested) to PTB's videocapture, so random windows from the desktop can be live-displayed into a PTB fullscreen onscreen window.

  • Screen('GetImage') can now automatically handle multi-sample anti-aliased drawbuffers without need for manual intermediate steps for readback of such buffers as MSAA resolved images.

  • PsychImaging 'PseudoGray' task can now also boost 10 bpc and 12 bpc framebuffers by up to 2.8 bits in grayscale precision in principle, although this is only very lightly and incompletely tested due to lack of suitable native 10/12 bpc display devices.

  • New PsychImaging 'UseSubpixelDrive task to allow to drive special medical imaging high precision grayscale displays with high precision, e.g., the "Eizo RadiForce GS-521".

  • New GetSecs subfunction [getSecsClock, wallClock, syncErrorSecs] = GetSecs('AllClocks'); returns not only regular GetSecs() timestamp as 'getSecsClock', but also a wall clock timestamp 'wallClock' in UTC world time. This 'wallClock' time can be OS synchronized to external time references, e.g., via NTP, to synchronize it with the clocks of other computers. Measures seconds since some reference point, 1.1.1970 00:00:00 UTC on Linux and OSX with microsecond resolution, seconds since 1.1.1601 00:00:00 UTC on MS-Windows with millisecond resolution. This may come in handy for interoperation with EGI Netstation EEG systems.

  • Some improvements to PsychColorCal routines by the Brainard lab.

  • Various fixes and small improvements.

  • Large amount of under the hood infrastructure prep work for supporting new VR HMD devices, but no support for new devices yet. Check for potential regressions if you use Psychtoolbox Oculus Rift DK1/DK2 support!

Btw. I've observed on some MS-Windows systems that UpdatePsychtoolbox - or more accurately the underlying svn Subversion command line tool - didn't do anything. It claimed a successfull update, but didn't update anything. This was also reported once in our Issue tracker. I don't know if this is a Windows specific svn bug, or something more widespread. Anyway, if UpdatePsychtoolbox doesn't upgrade about 176 files then something went wrong, and you'll need to use DownloadPsychtoolbox for a completely fresh download. Let us know if this happens on other systems than Windows.


Enjoy,

-mario


2
Hi Mario, I'm noticing on my retina iMac that this beta is displaying on only a quarter of the screen in e.g. VBLSyncTest, as if "UseRetinaResolution" was ON but the PanelFitter ignored the new size. PanelFitter default results are: [0 0 1920 1080 0 0 1920 1080 0 960 540], wrect from OpenWindow is [0 0 1920 1080]. I haven't yet tried to explicitly enable the PanelFitter as this is happening in PTB demo functions...

My Ubuntu 17.04 on a non-retina display seems to be working fine. Do we need to respecify anything for retina devices?

Ian
3
Dear Andreas,

Mark Moran from EGI support here. I'd like to offer a high level answer to your questions and can ask our engineering team for more technical information.

> OS X and Linux both have ntp clients by default. But sync to internet servers. That's only good for 10-100 ms accuracy. What you need to do is setup one of the local systems as an ntp server and sync the other systems against that.

That is correct. In our Net Amps 300, the mac clock functions as the NTP server and the mac clock is adjusted by the amp clock to stay synched with the amp. In our 400 system, the Amp is an internet device so functions as an NTP server directly and the mac clock is removed from the equation.

I have some reservations that a solution with NTP in general and a local server only in particular will not be as accurate as expected for several reasons. We can check accuracy empirically but I still do have concerns that sync may fail without obvious indications later, for example due to network trouble, standby, load, etc.
* I don't know whether EGI uses special clock hardware in the 400 type amp but with regular hardware clocks besides of clock drift there will be considerable (in the oder of several milliseconds) clock jitter and clock wander (change of drift; e.g. due to temperature changes). NTP-clients will only slowly adjust to server clock changes due to jitter and wander. The delayed NTP client's clock discipline adaptation might even have amplifying effects on inaccuracy. With 300 type system relying not on the amplifier but the Mac's hardware clock I would expect considerable offsets and other trouble. In the 400 type systems the situation is additionally complicated as three clocks have to be synchronized. In general the NTP algorithm relies on highly reliable hardware clocks.

Understood but do bear in mind we do have E-Prime using NTP to accurately send events the net station. That being said, I know it wasn't a easy task. I assume the above complications came into play and were resolved but I don't know the solution at that level. I think there is some confusion about the number of clocks though. On the 400 system, the amp's hardware clock is the master and the mac clock is irrelevant.

* I could not test any OS X 10.11 systems but at least on two (2012 Mac Mini, 2013 15" MacBook Pro) OS X 10.12 systems I observed serious problems with the NTP client while testing during last two days. We have a very good stratum 2 clock source with less than 0.5 ms delay. Both Macs consistently increased their offsets by up to more than +/-10 ms per hour without getting ever closer to a zero offset during a full day. Various NTP problems were reported on OS X since 10.9. One symptom appears to be that the timestamp of the drift file is not regularly updated. As this also happens with the homebrew NTP client on OS X but not on Linux this might also be an OS specific problem with the clock discipline algorithm.

See above, with the effort that went in to the E-Prime clock, I am not too surprised to hear that "out of the box" solutions are not perfect. We do have a client example that might help, I'll see if that might be sharable. It is in Objective C, so not directly usable.

Thanks,

Mark


On Fri, May 12, 2017 at 12:56 PM, Andreas Widmann <widmann@...> wrote:
Dear all,

I'm also trying to look into the synch problems together with Urte.

> OS X and Linux both have ntp clients by default. But sync to internet servers. That's only good for 10-100 ms accuracy. What you need to do is setup one of the local systems as an ntp server and sync the other systems against that.
I have some reservations that a solution with NTP in general and a local server only in particular will not be as accurate as expected for several reasons. We can check accuracy empirically but I still do have concerns that sync may fail without obvious indications later, for example due to network trouble, standby, load, etc.
* I don't know whether EGI uses special clock hardware in the 400 type amp but with regular hardware clocks besides of clock drift there will be considerable (in the oder of several milliseconds) clock jitter and clock wander (change of drift; e.g. due to temperature changes). NTP-clients will only slowly adjust to server clock changes due to jitter and wander. The delayed NTP client's clock discipline adaptation might even have amplifying effects on inaccuracy. With 300 type system relying not on the amplifier but the Mac's hardware clock I would expect considerable offsets and other trouble. In the 400 type systems the situation is additionally complicated as three clocks have to be synchronized. In general the NTP algorithm relies on highly reliable hardware clocks.
* I could not test any OS X 10.11 systems but at least on two (2012 Mac Mini, 2013 15" MacBook Pro) OS X 10.12 systems I observed serious problems with the NTP client while testing during last two days. We have a very good stratum 2 clock source with less than 0.5 ms delay. Both Macs consistently increased their offsets by up to more than +/-10 ms per hour without getting ever closer to a zero offset during a full day. Various NTP problems were reported on OS X since 10.9. One symptom appears to be that the timestamp of the drift file is not regularly updated. As this also happens with the homebrew NTP client on OS X but not on Linux this might also be an OS specific problem with the clock discipline algorithm.

With respect to the problem of the NetStation script waiting for the NTP timestamp: I got lost which version was now actually tested by Urte. The most recent version on Github waits in line 226 for a "Z"-acknowledgement of the S-command. This is not explicitly stated in the documentation. I would have expected that NetStation directly responds with the 8 NTP-timestamp bytes. Could you please try to comment this line and the following if-section?

Best,
Andreas

> Am 12.05.2017 um 14:23 schrieb Justin Ales justin.ales@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> :
>
>
>
> Yes this now possible in a forwards compatible way. It was already possible implicitly on Linux(but not guaranteed to stay the same across updates) as the ptb time is corrected by ntp if ntp is enabled.
>
> The update enables this to work on OS X and windows. By allowing correction of the ptb time to ntp time.
>
>
> OS X and Linux both have ntp clients by default. But sync to internet servers. That's only good for 10-100 ms accuracy. What you need to do is setup one of the local systems as an ntp server and sync the other systems against that.
>
> This should be able to achieve ~1 ms sync accuracy.
>
> To get better you can implement precision time protocol (ptp).
>
>
> Justin
>
> On Fri, May 12, 2017 at 12:19 PM iandol@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:
> Thanks for the Windows info! On macOS I used to use ntpd[1] which is command line only, and is cross-platform, but wonder whether anything else is recommended for Linux?
>
> ----
> [1] http://doc.ntp.org/4.1.0/ntpd. htm
>
>
>
>


4
Dear Mark,

> In our 400 system, the Amp is an internet device so functions as an NTP server directly and the mac clock is removed from the equation.
This is actually good news, thank you! So, you explicitly confirm that Mac time is irrelevant and all time stamps (data and all event types) are exclusively defined by the (400 system) amp? Then I would be somewhat more optimistic that we could get a sufficiently accurate solution if both, amp and stimulation PC clock hardware have reasonable quality. Urte, I will send you instructions on Monday how to activate detailed logging of ntp sync statistics on the Linux stimulation computer.

Mark, may I ask you one more question: Is there any way to use the chart port of the AV tester device with the 400 system amp?

Thank you! Best,
Andreas

> Am 13.05.2017 um 00:21 schrieb Mark Moran mmoran@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com>:
>
>
>
> Dear Andreas,
>
> Mark Moran from EGI support here. I'd like to offer a high level answer to your questions and can ask our engineering team for more technical information.
>
> > OS X and Linux both have ntp clients by default. But sync to internet servers. That's only good for 10-100 ms accuracy. What you need to do is setup one of the local systems as an ntp server and sync the other systems against that.
>
> That is correct. In our Net Amps 300, the mac clock functions as the NTP server and the mac clock is adjusted by the amp clock to stay synched with the amp. In our 400 system, the Amp is an internet device so functions as an NTP server directly and the mac clock is removed from the equation.
>
> I have some reservations that a solution with NTP in general and a local server only in particular will not be as accurate as expected for several reasons. We can check accuracy empirically but I still do have concerns that sync may fail without obvious indications later, for example due to network trouble, standby, load, etc.
> * I don't know whether EGI uses special clock hardware in the 400 type amp but with regular hardware clocks besides of clock drift there will be considerable (in the oder of several milliseconds) clock jitter and clock wander (change of drift; e.g. due to temperature changes). NTP-clients will only slowly adjust to server clock changes due to jitter and wander. The delayed NTP client's clock discipline adaptation might even have amplifying effects on inaccuracy. With 300 type system relying not on the amplifier but the Mac's hardware clock I would expect considerable offsets and other trouble. In the 400 type systems the situation is additionally complicated as three clocks have to be synchronized. In general the NTP algorithm relies on highly reliable hardware clocks.
>
> Understood but do bear in mind we do have E-Prime using NTP to accurately send events the net station. That being said, I know it wasn't a easy task. I assume the above complications came into play and were resolved but I don't know the solution at that level. I think there is some confusion about the number of clocks though. On the 400 system, the amp's hardware clock is the master and the mac clock is irrelevant.
>
> * I could not test any OS X 10.11 systems but at least on two (2012 Mac Mini, 2013 15" MacBook Pro) OS X 10.12 systems I observed serious problems with the NTP client while testing during last two days. We have a very good stratum 2 clock source with less than 0.5 ms delay. Both Macs consistently increased their offsets by up to more than +/-10 ms per hour without getting ever closer to a zero offset during a full day. Various NTP problems were reported on OS X since 10.9. One symptom appears to be that the timestamp of the drift file is not regularly updated. As this also happens with the homebrew NTP client on OS X but not on Linux this might also be an OS specific problem with the clock discipline algorithm.
>
> See above, with the effort that went in to the E-Prime clock, I am not too surprised to hear that "out of the box" solutions are not perfect. We do have a client example that might help, I'll see if that might be sharable. It is in Objective C, so not directly usable.
>
> Thanks,
>
> Mark
>
>
> On Fri, May 12, 2017 at 12:56 PM, Andreas Widmann <widmann@...> wrote:
> Dear all,
>
> I'm also trying to look into the synch problems together with Urte.
>
> > OS X and Linux both have ntp clients by default. But sync to internet servers. That's only good for 10-100 ms accuracy. What you need to do is setup one of the local systems as an ntp server and sync the other systems against that.
> I have some reservations that a solution with NTP in general and a local server only in particular will not be as accurate as expected for several reasons. We can check accuracy empirically but I still do have concerns that sync may fail without obvious indications later, for example due to network trouble, standby, load, etc.
> * I don't know whether EGI uses special clock hardware in the 400 type amp but with regular hardware clocks besides of clock drift there will be considerable (in the oder of several milliseconds) clock jitter and clock wander (change of drift; e.g. due to temperature changes). NTP-clients will only slowly adjust to server clock changes due to jitter and wander. The delayed NTP client's clock discipline adaptation might even have amplifying effects on inaccuracy. With 300 type system relying not on the amplifier but the Mac's hardware clock I would expect considerable offsets and other trouble. In the 400 type systems the situation is additionally complicated as three clocks have to be synchronized. In general the NTP algorithm relies on highly reliable hardware clocks.
> * I could not test any OS X 10.11 systems but at least on two (2012 Mac Mini, 2013 15" MacBook Pro) OS X 10.12 systems I observed serious problems with the NTP client while testing during last two days. We have a very good stratum 2 clock source with less than 0.5 ms delay. Both Macs consistently increased their offsets by up to more than +/-10 ms per hour without getting ever closer to a zero offset during a full day. Various NTP problems were reported on OS X since 10.9. One symptom appears to be that the timestamp of the drift file is not regularly updated. As this also happens with the homebrew NTP client on OS X but not on Linux this might also be an OS specific problem with the clock discipline algorithm.
>
> With respect to the problem of the NetStation script waiting for the NTP timestamp: I got lost which version was now actually tested by Urte. The most recent version on Github waits in line 226 for a "Z"-acknowledgement of the S-command. This is not explicitly stated in the documentation. I would have expected that NetStation directly responds with the 8 NTP-timestamp bytes. Could you please try to comment this line and the following if-section?
>
> Best,
> Andreas
>
> > Am 12.05.2017 um 14:23 schrieb Justin Ales justin.ales@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com>:
> >
> >
> >
> > Yes this now possible in a forwards compatible way. It was already possible implicitly on Linux(but not guaranteed to stay the same across updates) as the ptb time is corrected by ntp if ntp is enabled.
> >
> > The update enables this to work on OS X and windows. By allowing correction of the ptb time to ntp time.
> >
> >
> > OS X and Linux both have ntp clients by default. But sync to internet servers. That's only good for 10-100 ms accuracy. What you need to do is setup one of the local systems as an ntp server and sync the other systems against that.
> >
> > This should be able to achieve ~1 ms sync accuracy.
> >
> > To get better you can implement precision time protocol (ptp).
> >
> >
> > Justin
> >
> > On Fri, May 12, 2017 at 12:19 PM iandol@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:
> > Thanks for the Windows info! On macOS I used to use ntpd[1] which is command line only, and is cross-platform, but wonder whether anything else is recommended for Linux?
> >
> > ----
> > [1] http://doc.ntp.org/4.1.0/ntpd.htm
> >
> >
> >
> >
>
>
>
>
>