Please advise: Problem with a RUSHed movie

1
Dear Psychtoolbox Users and Gurus,

I have a problem with a RUSHed movie and I could use some help.
In a nutshell, I miss a video frame on about 3% of the trials.

The stimuli in my experiment are simple movies with the following
frame structure: 3 noise + 3 Gabor + 3 noise + 1 blank. All images
are 256 by 256 pixels. I RUSH the movie at MaxPriorityLevel as shown
below; the long integers are buffer pointers:

%% Begin RUSHed code ------------------------------
'SCREEN(235305168,'WaitBlanking');'
'startTime=GetSecs;'
'SCREEN('CopyWindow',235304896,235305168,[0 0 256 256],[257 639 513
895]);'
'SCREEN(235305168,'WaitBlanking',3);'
'SCREEN('CopyWindow',235305344,235305168,[0 0 256 256],[257 639 513
895]);'
'SCREEN(235305168,'WaitBlanking',3);'
'SCREEN('CopyWindow',235305472,235305168,[0 0 256 256],[257 639 513
895]);'
'SCREEN(235305168,'WaitBlanking',3);'
'SCREEN('CopyWindow',235305600,235305168,[0 0 256 256],[257 639 513
895]);'
'SCREEN(235305168,'WaitBlanking',2);'
'finishTime=GetSecs;'
%% End RUSHed code ------------------------------

Now, there are 11 frames in this simple movie and it should take
129.4 msec from startTime to finishTime at 85 Hz (11.76 msec/frame).
That's what happens on 97% of the trials. Occasionally, however,
finishTime-startTime==117.6 msec, which is one frame short.
About 30 trials out of 1200 have this problem. I couldn't find any
regularity it its appearance.

I can think of various reasons (e.g. inadequate CopyWindow speed)
that can slow the movie down. But why on earth would it finish earlier
than scheduled?

Any suggestions will be most welcome. The exact hardware and software
environment is summarized below. The same program ran without a
glitch on a different computer with a different video card before.

17" Hewlett Packard hp91 color monitor.
Driven by ATI Radeon 8500 10-bit video card (DualHead driver 1.0f72).
Resolution 1280x1024 pixels, 85 Hz refresh rate, 32-bit pixel depth.
Mac OS 9.2.2, MATLAB 5.2.1, PsychToolbox 2.53.

Another monitor is hooked to the built-in card of the Macintosh,
but all stimuli are presented on the Radeon 8500 (Screen 1).
Virtual memory is off. SCREEN Backgrounding is off.


% SCREENTest results, 26 Jan 2005: %%%%%%%%%%%%%%%%%%%%%%%%%%
*** ptime's PowerMac3,3/400, Mac OS 9.2.2
********************************
G4, 400 MHz, memory bus 100 MHz, 62.770 Mflop/s
Psychtoolbox 2.53, 12 August 2002, Matlab 5.2.1.1421
*** Screen 0
*************************************************************
ATI Radeon 7200, retail, PCI, aka "Radeon Mac Ed. (PCI)"
"ATY,RADEONp" (.Display_RADEON version 1.0f59) in slot SLOT-D
10 bit dacs. 1024x768 85 Hz. (56,60,65,67,70,72,75,76,85,90,100,120
Hz avail)
<...snip...>
*** Screen 1
*************************************************************
ATI Radeon 8500, port A
"ATY,R200i_A" (.Display_DualHead version 1.0f72) in slot SLOT-A
10 bit dacs. 1280x1024 85 Hz.
(56,60,65,67,70,72,75,76,85,90,100,120,150 Hz avail)
Prefs: cscGetClutBehavior, cscGetNextResolution,
SetClutDuplicates8Bits,
DipPriorityAfterSetClut, MinimumSetClutPriority 2, BlankingDuration
0.0030 s.
- - - - - - - - - - - - - - - - - - - - - - -
- -
pixel size 8 16 32 bits
pages 1 1 1
CopyWindow (ie CopyBits) 185 188 188 MB/s
CopyWindow (ie CopyBits) AGP 344 344 344 MB/s
CopyWindow (ie CopyBits) VRAM 1810 1801 1806 MB/s
SetClut suppresses ints. for 0.0 0.0 0.0 frames
LoadClut vs. GetClut? ( 8 bits) == == na
LoadClut vs. GetClut? (10 bits) == == na
<...snip...>


Any suggestions?
-- Alex

-------------------------------------------------------
Alexander A Petrov: apetrov (at) uci (dot) edu

Post-doctoral Researcher
Department of Cognitive Sciences
University of California, Irvine
http://www.socsci.uci.edu/~apetrov/

It is better to light one candle than to
curse the darkness. --- Confucius ---
-------------------------------------------------------
2
dear alex

you are posing a hard question. the psychtoolbox includes some
utilities to help you explore this kind of issue, e.g.
PeekBlankingTest.m and you might find it helpful to run them.

as you note, it is quite amazing that the time is SHORT by a frame. let
me describe one way in this might happen.

there was a period in which i found that some loops that included
WaitBlanking were racing at an incredible rate. it turned out that the
code was correctly waiting for the card to activate it's VBL interrupt,
but that the card then kept the interrupt request active for several
milliseconds, and a GHz processor can run up a huge number of cycles of
a trivial loop in a few milliseconds. i fixed this, in Screen.mex, by
adding a moratorium after each approved VBL event during which we
assume that the interrupt is spurious. the moratorium value is
user-adjustable but is set to 3 ms by default. this assumes that a new
interrupt occuring within 3 ms of the last should be ignored. that is a
perfectly safe and reasonable thing to assume provided the frame rate
is well below 300 Hz. if your video card occasionally maintains its
interrupt request for more than 3 ms then a single VBL event might get
counted twice because the moratorium would expire before the interrupt
did.

you can test this hypothesis easily by adjusting that parameter.
increasing it to 10 ms should eliminate the problem. reducing it below
3 ms should greatly exacerbate it.

Screen(w,'Preferences','BlankingDuration',0.01); % increase moratorium
to 10 ms

in your test, i suspect that all the calls to CopyWindow are
irrelevant. to demonstrate the problem i would guess that the following
is enough:

> %% Begin RUSHed code ------------------------------
> 'SCREEN(w,'WaitBlanking');'
> 'startTime=GetSecs;'
> 'SCREEN(w,'WaitBlanking',11);'
> 'finishTime=GetSecs;'
> %% End RUSHed code ------------------------------

you'll want to run this a large number of times and look at the
distribution of finishTime-startTime, which I suggest plotting as a
histogram. of course, if there are only two values then it may be
enough to just report the raw numbers.

good luck. i'd be interested to know whether this cures the problem.
please post here.

best

denis


On Jan 26, 2005, at 7:29 PM, apetrov1969 wrote:

>
>
> Dear Psychtoolbox Users and Gurus,
>
> I have a problem with a RUSHed movie and I could use some help.
> In a nutshell, I miss a video frame on about 3% of the trials.
>
> The stimuli in my experiment are simple movies with the following
> frame structure: 3 noise + 3 Gabor + 3 noise + 1 blank. All images
> are 256 by 256 pixels. I RUSH the movie at MaxPriorityLevel as shown
> below; the long integers are buffer pointers:
>
> %% Begin RUSHed code ------------------------------
> 'SCREEN(235305168,'WaitBlanking');'
> 'startTime=GetSecs;'
> 'SCREEN('CopyWindow',235304896,235305168,[0 0 256 256],[257 639 513
> 895]);'
> 'SCREEN(235305168,'WaitBlanking',3);'
> 'SCREEN('CopyWindow',235305344,235305168,[0 0 256 256],[257 639 513
> 895]);'
> 'SCREEN(235305168,'WaitBlanking',3);'
> 'SCREEN('CopyWindow',235305472,235305168,[0 0 256 256],[257 639 513
> 895]);'
> 'SCREEN(235305168,'WaitBlanking',3);'
> 'SCREEN('CopyWindow',235305600,235305168,[0 0 256 256],[257 639 513
> 895]);'
> 'SCREEN(235305168,'WaitBlanking',2);'
> 'finishTime=GetSecs;'
> %% End RUSHed code ------------------------------
>
> Now, there are 11 frames in this simple movie and it should take
> 129.4 msec from startTime to finishTime at 85 Hz (11.76 msec/frame).
> That's what happens on 97% of the trials. Occasionally, however,
> finishTime-startTime==117.6 msec, which is one frame short.
> About 30 trials out of 1200 have this problem. I couldn't find any
> regularity it its appearance.
>
> I can think of various reasons (e.g. inadequate CopyWindow speed)
> that can slow the movie down. But why on earth would it finish earlier
> than scheduled?
>
> Any suggestions will be most welcome. The exact hardware and software
> environment is summarized below. The same program ran without a
> glitch on a different computer with a different video card before.
>
> 17" Hewlett Packard hp91 color monitor.
> Driven by ATI Radeon 8500 10-bit video card (DualHead driver 1.0f72).
> Resolution 1280x1024 pixels, 85 Hz refresh rate, 32-bit pixel depth.
> Mac OS 9.2.2, MATLAB 5.2.1, PsychToolbox 2.53.
>
> Another monitor is hooked to the built-in card of the Macintosh,
> but all stimuli are presented on the Radeon 8500 (Screen 1).
> Virtual memory is off. SCREEN Backgrounding is off.
>
>
> % SCREENTest results, 26 Jan 2005: %%%%%%%%%%%%%%%%%%%%%%%%%%
> *** ptime's PowerMac3,3/400, Mac OS 9.2.2
> ********************************
> G4, 400 MHz, memory bus 100 MHz, 62.770 Mflop/s
> Psychtoolbox 2.53, 12 August 2002, Matlab 5.2.1.1421
> *** Screen 0
> *************************************************************
> ATI Radeon 7200, retail, PCI, aka "Radeon Mac Ed. (PCI)"
> "ATY,RADEONp" (.Display_RADEON version 1.0f59) in slot SLOT-D
> 10 bit dacs. 1024x768 85 Hz. (56,60,65,67,70,72,75,76,85,90,100,120
> Hz avail)
> <...snip...>
> *** Screen 1
> *************************************************************
> ATI Radeon 8500, port A
> "ATY,R200i_A" (.Display_DualHead version 1.0f72) in slot SLOT-A
> 10 bit dacs. 1280x1024 85 Hz.
> (56,60,65,67,70,72,75,76,85,90,100,120,150 Hz avail)
> Prefs: cscGetClutBehavior, cscGetNextResolution,
> SetClutDuplicates8Bits,
> DipPriorityAfterSetClut, MinimumSetClutPriority 2, BlankingDuration
> 0.0030 s.
> - - - - - - - - - - - - - - - - - - - - - - -
> - -
> pixel size 8 16 32 bits
> pages 1 1 1
> CopyWindow (ie CopyBits) 185 188 188 MB/s
> CopyWindow (ie CopyBits) AGP 344 344 344 MB/s
> CopyWindow (ie CopyBits) VRAM 1810 1801 1806 MB/s
> SetClut suppresses ints. for 0.0 0.0 0.0 frames
> LoadClut vs. GetClut? ( 8 bits) == == na
> LoadClut vs. GetClut? (10 bits) == == na
> <...snip...>
>
>
> Any suggestions?
> -- Alex
>
> -------------------------------------------------------
> Alexander A Petrov: apetrov (at) uci (dot) edu
>
> Post-doctoral Researcher
> Department of Cognitive Sciences
> University of California, Irvine
> http://www.socsci.uci.edu/~apetrov/
>
> It is better to light one candle than to
> curse the darkness. --- Confucius ---
> -------------------------------------------------------
>
>
>
>
>
>
> Post your message to: psychtoolbox@yahoogroups.com
> Please indicate OS9, OSX, or WIN version, and include your full name.
> Denis Pelli, David Brainard, and Allen Ingling.
> http://psychtoolbox.org
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
3
Dear PsychToolbox Users,

The expert advice of Denis Pelli solved the problem.
I included the following statement near the top of my program,
prior to the RUSHed loop:

%-- Increase WaitBlanking "moratorium" to 10 ms per Denis
Pelli's advice.
SCREEN(winPtr,'Preference','BlankingDuration',.010) ;

I ran the program and there were no irregularities this time!
I also tried several other BlankingDuration's and got the
following preliminary results:

BlDur Number of "short" movies (out of 1200+ trials)
----------------------------------------------------------------
3 ms 51, 33, 28, 9, 17, 18 % independent runs, default
5 ms 9
6 ms 5
7 ms 7
8 ms 12
9 ms 7
10 ms 0!!
----------------------

I will carry out more detailed experiments later and post them
here.
It seems, however, that Denis put me on the right track and I'll be
collecting human data soon.

Finally, let me point out how much I appreciate the service of
Denis Pelli, David Brainard, Allen Ingling, and the other
PsychToolbox developers. Not only do we have this software
available free of charge for the common good, but on top of this
there is a forum where anybody can ask for help and receive a
expert advice within a few hours. Many, many kudos (and
citations) to the PsychToolbox crew!

-- Alex

-------------------------------------------------------
Alexander A Petrov: apetrov@...

Post-doctoral Researcher
Department of Cognitive Sciences
University of California, Irvine
http://www.socsci.uci.edu/~apetrov/

It is better to light one candle than to
curse the darkness. --- Confucius ---
-------------------------------------------------------


--- In psychtoolbox@yahoogroups.com, Denis Pelli
<denis.pelli@n...> wrote:
> dear alex
>
> you are posing a hard question. the psychtoolbox includes
some
> utilities to help you explore this kind of issue, e.g.
> PeekBlankingTest.m and you might find it helpful to run them.
>
> as you note, it is quite amazing that the time is SHORT by a
frame. let
> me describe one way in this might happen.
>
> there was a period in which i found that some loops that
included
> WaitBlanking were racing at an incredible rate. it turned out that
the
> code was correctly waiting for the card to activate it's VBL
interrupt,
> but that the card then kept the interrupt request active for
several
> milliseconds, and a GHz processor can run up a huge number
of cycles of
> a trivial loop in a few milliseconds. i fixed this, in Screen.mex,
by
> adding a moratorium after each approved VBL event during
which we
> assume that the interrupt is spurious. the moratorium value is
> user-adjustable but is set to 3 ms by default. this assumes
that a new
> interrupt occuring within 3 ms of the last should be ignored.
that is a
> perfectly safe and reasonable thing to assume provided the
frame rate
> is well below 300 Hz. if your video card occasionally maintains
its
> interrupt request for more than 3 ms then a single VBL event
might get
> counted twice because the moratorium would expire before the
interrupt
> did.
>
> you can test this hypothesis easily by adjusting that parameter.
> increasing it to 10 ms should eliminate the problem. reducing
it below
> 3 ms should greatly exacerbate it.
>
> Screen(w,'Preferences','BlankingDuration',0.01); % increase
moratorium
> to 10 ms
>
> in your test, i suspect that all the calls to CopyWindow are
> irrelevant. to demonstrate the problem i would guess that the
following
> is enough:
>
> > %% Begin RUSHed code ------------------------------
> > 'SCREEN(w,'WaitBlanking');'
> > 'startTime=GetSecs;'
> > 'SCREEN(w,'WaitBlanking',11);'
> > 'finishTime=GetSecs;'
> > %% End RUSHed code ------------------------------
>
> you'll want to run this a large number of times and look at the
> distribution of finishTime-startTime, which I suggest plotting as
a
> histogram. of course, if there are only two values then it may be
> enough to just report the raw numbers.
>
> good luck. i'd be interested to know whether this cures the
problem.
> please post here.
>
> best
>
> denis
>
>
> On Jan 26, 2005, at 7:29 PM, apetrov1969 wrote:
>
> >
> >
> > Dear Psychtoolbox Users and Gurus,
> >
> > I have a problem with a RUSHed movie and I could use
some help.
> > In a nutshell, I miss a video frame on about 3% of the trials.
> >
> > The stimuli in my experiment are simple movies with the
following
> > frame structure: 3 noise + 3 Gabor + 3 noise + 1 blank. All
images
> > are 256 by 256 pixels. I RUSH the movie at MaxPriorityLevel
as shown
> > below; the long integers are buffer pointers:
> >
> > %% Begin RUSHed code ------------------------------
> > 'SCREEN(235305168,'WaitBlanking');'
> > 'startTime=GetSecs;'
> > 'SCREEN('CopyWindow',235304896,235305168,[0 0 256
256],[257 639 513
> > 895]);'
> > 'SCREEN(235305168,'WaitBlanking',3);'
> > 'SCREEN('CopyWindow',235305344,235305168,[0 0 256
256],[257 639 513
> > 895]);'
> > 'SCREEN(235305168,'WaitBlanking',3);'
> > 'SCREEN('CopyWindow',235305472,235305168,[0 0 256
256],[257 639 513
> > 895]);'
> > 'SCREEN(235305168,'WaitBlanking',3);'
> > 'SCREEN('CopyWindow',235305600,235305168,[0 0 256
256],[257 639 513
> > 895]);'
> > 'SCREEN(235305168,'WaitBlanking',2);'
> > 'finishTime=GetSecs;'
> > %% End RUSHed code ------------------------------
> >
> > Now, there are 11 frames in this simple movie and it should
take
> > 129.4 msec from startTime to finishTime at 85 Hz (11.76
msec/frame).
> > That's what happens on 97% of the trials. Occasionally,
however,
> > finishTime-startTime==117.6 msec, which is one frame
short.
> > About 30 trials out of 1200 have this problem. I couldn't find
any
> > regularity it its appearance.
> >
> > I can think of various reasons (e.g. inadequate CopyWindow
speed)
> > that can slow the movie down. But why on earth would it
finish earlier
> > than scheduled?
> >
> > Any suggestions will be most welcome. The exact hardware
and software
> > environment is summarized below. The same program ran
without a
> > glitch on a different computer with a different video card
before.
> >
> > 17" Hewlett Packard hp91 color monitor.
> > Driven by ATI Radeon 8500 10-bit video card (DualHead
driver 1.0f72).
> > Resolution 1280x1024 pixels, 85 Hz refresh rate, 32-bit pixel
depth.
> > Mac OS 9.2.2, MATLAB 5.2.1, PsychToolbox 2.53.
> >
> > Another monitor is hooked to the built-in card of the
Macintosh,
> > but all stimuli are presented on the Radeon 8500 (Screen 1).
> > Virtual memory is off. SCREEN Backgrounding is off.
> >
> >
> > % SCREENTest results, 26 Jan 2005:
%%%%%%%%%%%%%%%%%%%%%%%%%%
> > *** ptime's PowerMac3,3/400, Mac OS 9.2.2
> > ********************************
> > G4, 400 MHz, memory bus 100 MHz, 62.770 Mflop/s
> > Psychtoolbox 2.53, 12 August 2002, Matlab 5.2.1.1421
> > *** Screen 0
> > *************************************************************
> > ATI Radeon 7200, retail, PCI, aka "Radeon Mac Ed. (PCI)"
> > "ATY,RADEONp" (.Display_RADEON version 1.0f59) in slot
SLOT-D
> > 10 bit dacs. 1024x768 85 Hz.
(56,60,65,67,70,72,75,76,85,90,100,120
> > Hz avail)
> > <...snip...>
> > *** Screen 1
> > *************************************************************
> > ATI Radeon 8500, port A
> > "ATY,R200i_A" (.Display_DualHead version 1.0f72) in slot
SLOT-A
> > 10 bit dacs. 1280x1024 85 Hz.
> > (56,60,65,67,70,72,75,76,85,90,100,120,150 Hz avail)
> > Prefs: cscGetClutBehavior, cscGetNextResolution,
> > SetClutDuplicates8Bits,
> > DipPriorityAfterSetClut, MinimumSetClutPriority 2,
BlankingDuration
> > 0.0030 s.
> > - - - - - - - - - - - - - - - - - - - - - -
-
> > - -
> > pixel size 8 16 32 bits
> > pages 1 1 1
> > CopyWindow (ie CopyBits) 185 188 188 MB/s
> > CopyWindow (ie CopyBits) AGP 344 344 344 MB/s
> > CopyWindow (ie CopyBits) VRAM 1810 1801 1806 MB/s
> > SetClut suppresses ints. for 0.0 0.0 0.0 frames
> > LoadClut vs. GetClut? ( 8 bits) == == na
> > LoadClut vs. GetClut? (10 bits) == == na
> > <...snip...>
> >
> >
> > Any suggestions?
> > -- Alex
> >
> > -------------------------------------------------------
> > Alexander A Petrov: apetrov (at) uci (dot) edu
> >
> > Post-doctoral Researcher
> > Department of Cognitive Sciences
> > University of California, Irvine
> > http://www.socsci.uci.edu/~apetrov/
> >
> > It is better to light one candle than to
> > curse the darkness. --- Confucius ---
> > -------------------------------------------------------