http://groups.yahoo.com/group/psychtoolbox/message/388
From:  Rajeev Raizada <raj@n...> 
Date:  Fri Mar 9, 2001  7:55 pm 
Subject:  Prob. with stim duration: sometimes one frame too short

Dear Psychtoolbox Users,

I am trying to get stimuli presented for exactly 100ms using waitblanking
to wait for 6 frames on a monitor which screen('framerate') identifies as
60.006Hz. I'm checking the timings of the stimuli which are produced using
a photodiode connected to a digital oscilloscope, and I find that the
visual stimulus (simply a white disk) sometimes stays on for the desired
six frames, but quite frequently is only on for 5 frames.

The diode and scope themselves seem to be very accurate, e.g. they easily
pick up the waveform of the screen-refreshes which occur while the
stimulus is on. So, I don't think that the calibration measurement is the
problem.

Here's the relevant snippet of my code:

SCREEN('CopyWindow',imagePtr(1),window,imageRect,destRect,'srcCopyQuickly');
% Copy the offscreen circle onto the onscreen window

%%%%%%%%%%%%%%%%% Wait six frames before erasing stimulus with a mask

SCREEN(window,'WaitBlanking',6);
SCREEN('CopyWindow',imagePtr(2),window,imageRect,destRect,'srcCopyQuickly');
% Copy the offscreen black mask onto the onscreen window

I'm wondering whether I might be using Waitblanking incorrectly.
Perhaps the number of frames that it actually waits is dependent upon when
in the ongoing frame-refresh cycle it is actually called? I'm not sure,
that's my best guess at the moment.

Also, I'm wondering whether this might be a property of the fact that I am
on a flat-screen monitor (this is not the monitor which I will be using
for the actual expt). However, as far I can tell this should only give me
a long offset-decay, rather than making me lose a whole frame of the
visual stimulus.

I'm not using "rush", so I haven't tried playing with Virtual Memory,
which is currently on (am I right in thinking that this only makes a
difference with "rush"-ed things?). My Mac doesn't seem to run so well
when I turn the Virtual Memory off, but obviously I can try doing this if
there is reason to think that this is the cause of losing the frame.

Also, screentest gives me an interesting error message, which perhaps
could be the route of the problem, but which I don't really understand.

WARNING from DriverTest:
Inconsistent frame rate: SetClut 60 Hz vs interrupt 56 Hz.
driver =
secs: 0.2000
windowPtrOrScreenNumber: 0
setClutDriverAwaitsBlanking: 1
interruptOnBlanking: 1
setClutFraction: 0.0400
priority: 0
waitError 0.0 ms,noWaitError 8.3 ms,deadError 9.6 ms,badError 16.7 ms
SetClut 60.0 Hz (17 ms) vs interrupt 56.3 Hz (18 ms)
pixelSize 16
SetClutDriverWaitsForBlanking 1
SetClut period 17 ms, or 17 ms with delay 8 ms
InterruptToSetClutEndSecs 0 0 0 0 0 0 0 0 0 0 ms
interruptOnBlanking 1
Please send this report to denis & david:
web mailto:psychtoolbox@p...

Here are the technical specs for my Mac, from screentest:

****** Russell Poldrack's Power Mac G4/450, Mac OS 9.0.2, Using Virtual
Memory. ******
G4, 450 MHz, memory bus 100 MHz, 58.814 Mflop/s
PsychToolbox 2.44, 7 August 2000, MATLAB 5.2.0.3084
QuickTime 4.1.2
FileSharing is on.
Warning: VM is on. This makes it unsafe to raise priority to minimize
interrupts.
SUGGESTION: Use Memory control panel to turn off Virtual Memory.
Screen saver present, now disabled.
Using UpTime-based timing, which is very accurate and reliable.
*** Screen 0 *************************************************************
ATY,Rage128Ps (.Display_Rage128 version 1.0b41) in slot SLOT-A
8 bit dacs. 1024x768 60 Hz.
NOTE: DipPriorityAfterSetClut is true. Works around Rage128 driver bug.
NOTE: MinimumSetClutPriority is 2. Works around Rage128 driver bug.

Any help would be greatly appreciated.
Many thanks,

Rajeev Raizada
Postdoctoral Research Fellow
MGH-NMR Center / Harvard Medical School
Building 149, 13th Street,
Charlestown, MA 02129
E.mail: raj@n...

#######################################################################
http://groups.yahoo.com/group/psychtoolbox/message/389

From:  David Brainard <brainard@p...> 
Date:  Fri Mar 9, 2001  10:15 pm 
Subject:  Re: [psychtoolbox] Prob. with stim duration: sometimes one frame too short


>SCREEN('CopyWindow',imagePtr(1),window,imageRect,destRect,'srcCopyQuickly');
> % Copy the offscreen circle onto the onscreen window
>
>%%%%%%%%%%%%%%%%% Wait six frames before erasing stimulus with a mask
>
>SCREEN(window,'WaitBlanking',6);
>SCREEN('CopyWindow',imagePtr(2),window,imageRect,destRect,'srcCopyQuickly');
> % Copy the offscreen black mask onto the onscreen window

I'd add a call to WaitBlanking before you blit in the stimulus to begin with.
This will ensure that your code is always starting at the same time relative
to blanking and is a good idea even if it doesn't solve your problem.

>Also, I'm wondering whether this might be a property of the fact that I am
>on a flat-screen monitor (this is not the monitor which I will be using
>for the actual expt). However, as far I can tell this should only give me
>a long offset-decay, rather than making me lose a whole frame of the
>visual stimulus.

I agree, the type of monitor shouldn't affect this.

>I'm not using "rush", so I haven't tried playing with Virtual Memory,
>which is currently on (am I right in thinking that this only makes a
>difference with "rush"-ed things?). My Mac doesn't seem to run so well
>when I turn the Virtual Memory off, but obviously I can try doing this if
>there is reason to think that this is the cause of losing the frame.

In general, I recommend turning virtual memory off for experiments.
I am surprised your Mac has more trouble with it on than off, unless
you are really short on real memory. Usually it is the other way around.

If adding the initial call to WaitBlanking doesn't fix your problem, then
the next thing I would recommend is using Rush in the stimulus
display section. Otherwise you can get a system service interrupt
at a time you don't want and this can screw up the timing.

Denis is the DriverTest guru, I'll leave this to him.

DB
 

#######################################################################
http://groups.yahoo.com/group/psychtoolbox/message/391

From:  "Rajeev Raizada" <raj@n...> 
Date:  Sat Mar 10, 2001  10:23 am 
Subject:  Re: Prob. with stim duration: sometimes one frame too short

--- In psychtoolbox@y..., David Brainard <brainard@p...> wrote:

Many thanks for the reply!

> I'd add a call to WaitBlanking before you blit in the stimulus to
> begin with. This will ensure that your code is always starting at
> the same time relative to blanking and is a good idea even if it
> doesn't solve your problem.

Actually, I already have this in the program.
I should have included it in the snippet I put in the mail, apologies.
So, I don't think this can be the solution.

> In general, I recommend turning virtual memory off for experiments.
> I am surprised your Mac has more trouble with it on than off

You are right to be surprised - I wrote this wrong! Oops!
I meant that it sometimes has a problem with it off.
However, I can try running the expt with it off, I haven't done that
yet.

> If adding the initial call to WaitBlanking doesn't fix your
> problem, then
> the next thing I would recommend is using Rush in the stimulus
> display section. Otherwise you can get a system service interrupt
> at a time you don't want and this can screw up the timing.

I'll try this. However, the lost-frame happens at least half the
time, whereas I guess that system interrupts which would be at just
the right time for killing one of the six frames would be quite rare.

So, I still don't quite know what the solution is. However,
even if I don't fix it, it's not completely crucial for this
particular expt.

A question about delays: do you think that making delays with
Waitsecs might be more accurate than waiting for a specific number of
frames, if I can't sort out the frame-dropping problem?

Many thanks indeed for your help,

Raj

#######################################################################
http://groups.yahoo.com/group/psychtoolbox/message/392

From:  Denis Pelli <denis@p...> 
Date:  Sat Mar 10, 2001  10:44 pm 
Subject:  Re: Prob. with stim duration: sometimes one frame too short

dear rajeev

here are some answers to what david hasn't already covered.

as david noted, the code above can only work reliably if you call
waitblanking before ALL the calls to copywindow. On most computers today
copywindow will run faster if you OMIT 'srcCopyQuickly'. So your snippet
SHOULD read:

SCREEN(window,'WaitBlanking',1);
SCREEN('CopyWindow',imagePtr(1),window,imageRect,destRect);
SCREEN(window,'WaitBlanking',6);
SCREEN('CopyWindow',imagePtr(2),window,imageRect,destRect);

Then you say many confusing things about RUSH and Virtual Memory, ending
by saying that you don't really care whether you get good timing or not.

If you do care about timing then you should use RUSH. For RUSH to be
effective you'll have to turn VM off. That, in turn, may force you to buy
memory. At $0.50/MB you can probably afford to buy a lot, and I suggest
you end up with at least 256 MB.

If an interrupt (or VM page fault) occurs while a window is being copied,
the time to end of that copying operation will be increased. if your
image is big this increase may cause the time to exceed a frame. if you
take more than a frame time to copy an image then there's nothing that
our software can do to get you back on your missed schedule. time travel
is not a software solution.

i don't yet have any experience with flat screen displays, but, alas, it
IS possible that this would produce strange results. With a digital
display there's no problem, but if you're driving your flat panel through
an analog input then the display is very likely to have its own internal
frame rate which is independent of the frame rate of your video card. the
flat panel may resample the analog video and display at its own rate.
Such resampling could easily miss frames periodically.

the warning from DriverTest is innocuous. It has a low threshold for
reporting anomalies.

best

denis

#######################################################################
http://groups.yahoo.com/group/psychtoolbox/message/393

From:  David Brainard <brainard@p...> 
Date:  Tue Mar 13, 2001  3:01 pm 
Subject:  Re: Prob. with stim duration: sometimes one frame too short
 
>
>Do you know how I could find out whether this is the case or not?
>Also, how can I determine whether I am driving the projector through
>digital or analog input?

For the timing, the best thing is to generate a synchronization
pulse in your display loop. On older Macs, this was easy using
SERIAL('CTS') but with a USB Mac I don't know a trivial way to do it.
Maybe you could write something to the audio port using SND, but
I don't know what the timing properties of that are. Once
you've got a pulse you can compare it's time to screen events
(using your scope and photometer) and determine whether
anything strange is happening in the display electronics.
Another approach would be to try to make sense of the
signal driving the monitor with your scope, then compare
this to the light output of the display.

DB

#######################################################################

#######################################################################
