[open] Visual Presentation Times Vary Massively and Regularly.

booradley

EDIT: No need to read the disheartened rant below. The end comment reveals all.

Hi folks,

As you may or may not know I've been working on an experiment where audio stimuli has been synchronised almost exactly with visual stimuli.

However, the length of time that visual stimuli is held to the screen is very inaccurate.

I instruct OS to display one canvas which has a circle for 0ms (monitor refresh rate is 100Hz and in the past we've had to reduce to the refresh rate number 1 frame below the one we want) and this is followed by another canvas with a circle in the same position for 40ms (which equates to 50ms). In total this should mean a circle being displayed for 60ms.

When running a small number of trials in a block there is some variation. The majority are displayed for 60ms as instructed but there is some with wild variation anywhere between 70ms and 120ms.

This gets even more bizarre when I increase the number of trials per block. In fact it has the reverse effect.

The displays times plummet to 20ms in some cases after an X amount of blocks and appear to hover around the 30ms point. This is even perceptually noticeable without even checking output (which does confirm this plummet).

This really is the last hurdle before running this experiment. We've achieved so much with getting highly accurate audio/visual syncing and have been working on it for at least 4 months straight now (not including Xmas break).

Is there any reason this may be happening? Is there a solution to it?

Thanks for your time,

A disheartened Boo.

booradley

Update: I've also just had a word with my supervisor and he speculates that it may be some problem with memory where there is an unwanted increment of some kind which may explain the gradual deterioration in timing. Just throwing it out there.

booradley

Well. After a mini-marathon of debugging I discovered a piece of code in the wrong loop. Naughty inline script. Ahem...

Basically panic over.

There are still instances of frames being held to the screen longer than they are instructed to be but after testing with 6 blocks totalling 162 trials the instances of this occurring is just over 6%. I think this is an acceptable variation since all but one was 10ms extra (granted the other was 140ms!).

I'll spend the rest of the evening making the experiment look shiny for the participants.

If anyone has any suggestions on how to reduce that 6% variation further it is most welcome but I think we'll be okay as is.

Boo.

Edwin

Hi Boo,

Glad that the panic is over! Is the sketchpad you are talking about at the end of your trial sequence, perhaps? The delay could then be the preparation of the following trial. Otherwise: what is directly behind the sketchpad? If this is a piece inline scripting, for example, some delay might be added by Python interpreting the code in your inline script.

Best,

Edwin

booradley

Hi Edwin,

There is indeed an inline script just before the sketchpad. This is need in order to flip the audio switch once the photodiode picks up the stimuli on the following sketchpad.

I'm guessing there is little that can be done about this?

Boo.

Edwin

Hi Boo,

Depending on how you calculate the presentation times, this could indeed cause a bit of irregular delay. Could you give us your trial sequence and your way of calculating the presentation time for the relevant frames?

Thanks!

boris

Hi Boo,

If anyone has any suggestions on how to reduce that 6% variation further it is most welcome but I think we'll be okay as is.

I guess that you:
1) killed the maximum of processes running in the same time as your experiment
2) disabled your antivirus
3) unplugged your computer from the internet

All these could influence badly the timing on your machine.

booradley

Hi Boris,

Thanks for the suggestions. We have indeed been implementing these already.

Thanks again,

Boo.

booradley

Hi Edwin,

Here is the sequence in question:

file:///G:/sequence.bmp

In this sequence the Sketchpads beginning with 'Diode' are default (depending on which condition) and are held for one frame (10ms). These are simply in place to accommodate the triggering of a photodiode via one frame flashing a white rectangle (hidden from participant view).

The Sketchpads after that, with the same titles minus 'Diode', are held to the screen for a specified duration that is garnered from an earlier staircase loop.

I have a piece of code in place that takes the 'Diode' Sketchpad's duration into account and adjusts the duration variable accordingly (subtracting10ms).

Therefore when calculating how long the Sketchpad/s were held to the screen before the presentation of 'BothCircles' Sketchpad I subtract the time stamp of the 'Diode' Sketchpad in question from BothCircles since this takes into account all the frames I'm concerned about.

If this doesn't make sense let me know and I'll try again at explaining it.

Boo.

booradley

Sorry,

Here's a working link to an image of the sequence:

http://i.imgur.com/HCclOwu.png

Boo.

booradley

Hi folks,

Any final suggestions before we run?

Thanks,

Boo.

Edwin

Hi Boo,

At risk are 'buffer1' and 'LeftCircle1', since you do some inline scripting directly after these (it is difficult to predict how long it takes before code is run through). You could add a blank sketchpad right after any sketchpad you would want to present for 1 frame only.

Good luck!

booradley

Hi Edwin,

Thanks for that!

Boo.