PXLab Timing

This is preliminary text and not all data mentioned in this text have been collected with the latest version of PXLab


Time Measurement in PXLab

Time measurement is a critical task of any software which runs psychological experiments. So one of the first questions to be asked when thinking about time measurement is how precise can it be and how precise must it be. In general it seems that for most psychological experiments stimulus timing precision should be around 1 ms. Although when looking closer then this requirement seems too restrictive. Suppose we make a response time experiment with an optical stimulus shown on a video monitor. By definition the response time is the time period between the start of the stimulus on the screen and the subject's response. But when does the stimulus on the screen start? Assume the screen has a refresh rate of 100 Hz. This means that a single image frame takes about 10 ms. The 10 ms, however, cover both the actual display duration and the vertical retrace period. The following image shows the vertical retrace period of a video signal.

The lower trace is the vertical synchronization signal of the VGA-port and the upper trace is the video signal of the blue channel. On the left the graphics board is set to a refresh rate of 60 Hz and on the right the refresh rate is 100 Hz. We see that the verical blanking interval has a duration of about 0.74 ms at 60 Hz and of about 0.56 ms at 100 Hz refresh rate.

Experimental control software will usually synchronize its time measurement with the vertical retrace. This means that it synchronizes to the vertical retrace signal shown in the lower trace of the previous pictures. If the signal is a single line at the screen center it will be shown exactly 5.28 ms after the vertical retrace signal and thus the response times measured will be 5.28 ms too long. Most signals will not be single video lines. Suppose the signal is at the screen center and occupies 20 % of the vertical screen size. The signal will then start 4.34 ms after the vertical sync and will need 1.89 ms to be fully shown.

The good news is that in most cases these delays don't matter, since the only timing that counts are differences between response times. These considerations, however, make clear that we always have to look carefully at the physical stimulus properties when exact timing is important. And we always have to keep in mind that video signals are time processes and these might interfere with what is required for stimulus timing. We will come back to this slater when we look at the duration of stimuli presented on video monitors.

When PXLab measures time it always uses the best available clock on the system it runs on. Starting with Java 5 the Java system library contains a method to get relative time with nanosecond resolution. This timer is based on the best available hardware and seems to be very precise. It is not so easy to check how precise the timer actually is, since this would require an independent source of timing signals which can communicate with the Java software. PXLab contains some application programs which may be used to check a system's timing precision.

Timer Granularity

The application de.pxlab.pxl.tools.timing.TimerGranularity tries to check the granularity of the internal timer. It reads time values as fast as possible and checks how these values change. If the timer returns values of nanosecond resolution but change only every n ms then its granularity would be n ms. On a Windows system the program will usually report that it could not measure timer granularity because it is too small. In this case reading the timer takes longer than its granularity is. On my notebook the output of the program is
   HiresClock granularity could not be measured!
   It must be less than 1214 ns.
This tells us that the timer value had changed at every read operation and reading the timer and comparing the value read to the previous value took about 1200 ns. The timer's granularity must be less than this which is a highly satisfactory result.

For comparison the same program on a 3 GHz PC tells us

   HiresClock granularity could not be measured!
   It must be less than 381 ns.
In this case it takes about 380 ns to read the high resolution timer.

Timing Precision

The application de.pxlab.pxl.tools.timing.VideoTiming uses the graphics system as an independent timing source for checking the timing precision of the internal clock. Here is a sample output for a notebook with an Intel Centrino 1.5 GHz CPU:
   Nominal refresh rate          = 60 Hz
   Nominal frame duration        = 16666666 ns
   Number of frames observed     = 200
   Actual frame duration minimum = 16628650 ns
   Actual frame duration maximum = 16692624 ns
   Number of single frame misses = 0
   Actual frame duration mean    = 16661052 ns
   Actual frame duration sd      = 7722 ns [0.0463 %]
   Target duration               = 199999992 ns
   Actual duration minimum       = 199900546 ns
   Actual duration maximum       = 199964800 ns
   Actual duration mean          = 199932638 ns
   Actual duration sd            = 12976 ns [0.0065 %]

The graphics systems reports a refresh rate of 60 Hz. Now VideoTiming measures 200 single video frames. The nominal frame duration is 16.666 ms and the measurement shows that the lowest value measured is 16.628 ms and the highest value measured is 16.692 ms. The mean is 16.661 ms and the standard deviation is 0.0463 % of the mean. It also shows that the vertical retrace synchronization software did not miss any of the frames. The second part of the output refers to a timing interval of about 200 ms as a nominal target duration which corresponds to a standard response time. The program measures the duration of the corresponding number of video frames. The protocol tells us that minimum, maximum, and mean do hardly deviate at all from the target duration. The standard deviation of the measured time intervals is only 0.0065 % of the mean. Even if we assume that the video signal is perfectly constant in its timing properties then these data show that the internal clock is an extremely precise and reliable measurement device.

Again for comparison here is the output of de.pxlab.pxl.tools.timing.VideoTiming for a 3 GHz PC with a display system running at a refresh rate of 75 Hz:

Nominal refresh rate          = 75 Hz
Nominal frame duration        = 13333333 ns
Number of frames observed     = 200
Actual frame duration minimum = 13283347 ns
Actual frame duration maximum = 13379203 ns
Number of single frame misses = 0
Actual frame duration mean    = 13332691 ns
Actual frame duration sd      = 6627 ns [0.0497 %]
Target duration               = 199999995 ns
Actual duration minimum       = 199978057 ns
Actual duration maximum       = 200003891 ns
Actual duration mean          = 199990143 ns
Actual duration sd            = 7572 ns [0.0038 %]

This also shows the satisfactory precision of Java time measurement.

Wait Interval Precision

Java is a multithreaded language and the Windows operating system is multitasking such that there always are multiple tasks running simultanously. PXLab experiments run in their own thread and use additional threads for response event handling and for special tasks like running animations, movies, or sound. Furthermore PXLab programs must be well behaving and not occupy all system resources in order to integrate well in a useful development environment. In this context it poses a special problem to create precise wait intervals. Suppose we want to show a stimulus for 200 ms. We then have to switch it on, wait for 200 ms and then switch the stimulus off. While we wait we might also accept subject responses and thus the program both has to take care of the proper wait interval and for handling response events.

The application de.pxlab.pxl.tools.timing.Wait checks the precision of wait intervals. It computes a random target time from 1 to 120 ms and then executes a wait for the respective duration. The output looks like this:

Time	Wait	n
1	1	5
2	2	9
3	3	4
4	4	6
5	5	5
6	6	10
7	7	5
8	8	4
9	9	3
10	10	5
11	11	6
12	12	3
13	13	5
14	14	2
15	15	5
16	16	3
17	-	0
18	18	5
19	19	5
20	20	4
21	21	5
...
118	118	8
119	119	8
120	120	3

The first column contains the target waiting time and the second column contains the duration of the actual waiting time in ms. The third column contains the number of samples for the respective duration. If PXLab's wait method works properly then the content of the first and second column should be identical. Note that the entry in the second column may be missing if by chance it had not been sampled.

Testing the Lowest Video Duration Limit

The design file VideoFrameDurationLimit01.pxd allows testing for the lowest video display duration limit. It shows a single vertical bar. Its duration is defined by the parameter dt in the global assignments section. Video display of the bar is synchronized to the vertical retrace. This means that the actual duration observed is an integer multiple of the video frame duration. To see the lowest display duration limit set the duration parameter dt to something which is less than a single video frame duration. Then start the program and use command line options to define the video system timing. Here is an example for a proper command line:
   java de.pxlab.pxl.run.ExRun -S 4 -w 800 -h 600 -R 100 -D time 

This sets the screen parameters to a resolution of 800x600 pixels at a resfresh rate of 100 Hz. Note that setting the video parameters requires that screen mode 4 is used which is a full screen exclusive mode. Only then may the video system parameters be changed. Also note that debugging of timing has been activated by setting option '-D time'. The timing data are stored in file 'pxlab.dat'. Here is an example output where the intended duration has been set to 6 ms:

6	1153998203.0712	1153998213.0674	9.9962	3.9962
6	1153998502.9192	1153998512.8943	9.9751	3.9751
6	1153998812.7624	1153998822.7367	9.9743	3.9743
6	1153999112.6111	1153999122.5857	9.9746	3.9746
6	1153999412.4622	1153999422.4425	9.9802	3.9802
6	1153999712.3085	1153999722.2857	9.9772	3.9772
6	1154000012.1609	1154000022.1316	9.9707	3.9707
6	1154000312.0068	1154000321.9796	9.9728	3.9728
6	1154000611.852	1154000621.8374	9.9854	3.9854
6	1154000911.7053	1154000921.6895	9.9842	3.9842

The file contains data from 10 measurement cycles. The first column is the intended duration. The 2nd and 3rd column are the time points when the bar started and when it has been repaced by the following display object respectively. The 4th column is the actual duration and the 5th column is the difference between the actual and the intended duration. As expected, every display duration is at an integer multiple of the video frame duration which nominally is at 10 ms.

Setting the intended duration to 60 ms under the same video system condition results in this output:

60	1154067735.3729	1154067795.3276	59.9546	-0.0454
60	1154068085.1843	1154068145.1493	59.9649	-0.0351
...
60	1154070883.7831	1154070943.7315	59.9485	-0.0515

Here too the actual duration is an integer multiple of the video frame duration.

It may be instructive to look at the debugging output also. Here is a short section of the debugging protocol. It covers the last trial:

PresentationManager.showDisplayList(): Creating buffer for Trial.ClearScreen:Pre [0]
ExperimentalDisplayDevice.createMemoryBuffer(): Acceleration is not required.
ExperimentalDisplayDevice.createMemoryBuffer(): Created standard image buffer.
  The buffer is not accelerated.
  The buffer is not volatile.
  Accelerated memory available: 80908 KB
  Remaining accelerated memory: 80908 KB
PresentationManager.showDisplayList(): Creating buffer for Trial.SimpleBar [0]
ExperimentalDisplayDevice.createMemoryBuffer(): Acceleration is required.
ExperimentalDisplayDevice.createMemoryBuffer(): Created volatile image buffer.
  The buffer is accelerated.
  The buffer is true volatile.
  Accelerated memory available: 80908 KB
  Remaining accelerated memory: 79008 KB
PresentationManager.showDisplayList(): Creating buffer for Trial.ClearScreen:Post [0]
ExperimentalDisplayDevice.createMemoryBuffer(): Acceleration is required.
ExperimentalDisplayDevice.createMemoryBuffer(): Created volatile image buffer.
  The buffer is accelerated.
  The buffer is true volatile.
  Accelerated memory available: 79008 KB
  Remaining accelerated memory: 77108 KB
Start display list:           1154070629

--- Trial.ClearScreen:Pre[0] [M]
Prepare timing group:         1154070668
Image buffer shown: --------> 1154070681
Intended duration:            200000000
Acc. image preloading time:   3.507238
Fixed duration:               192419546
Timing group finished:        1154070877

--- Trial.SimpleBar[0] [M]
Prepare timing group:         1154070877
Preloaded image shown: -----> 1154070884
Intended duration:            60000000
Acc. image preloading time:   0.449772
Fixed duration:               55462684
Timing group finished:        1154070940

--- Trial.ClearScreen:Post[0] [M]
Prepare timing group:         1154070940
Preloaded image shown: -----> 1154070944
Intended duration:            1000000
Fixed duration:               1000000
Timing group finished:        1154070945

The debugging protocol starts with buffer allocation. We have 3 display objects in a trial and every display object has a single timing group such that three screen buffers are allocated. The first display object (ClearScreen) uses non-critical timing and thus gets a standard buffer allocated while the 2nd and 3rd object use video synchronized timing such that the system tries to allocate accelerated video buffers for these objects. The messages

  The buffer is accelerated.
  The buffer is true volatile.
indicate that accelerated video buffer allocation had been successful. Thus the buffers for the SimpleBar object and for the ClearScreen:Post object are located in accelerated video memory. This is reflected in the line saying
Acc. image preloading time:   3.507238
which tells us that the image preload of the SimpleBar object took 3.5 ms. The main timing control in the debug protocol is contained in the lines
...
Image buffer shown: --------> 1154070681
...
Preloaded image shown: -----> 1154070884
...
Preloaded image shown: -----> 1154070944
...
These lines contain the actual times when the respective display objects have appeared on the screen. The time difference between the 2nd and 3rd entry is 60 ms which exactly corresponds to the actual duration of the SimpleBar stimulus object.

All these data indicate that the system described here is capable of showing video display objects at the physical limit of a single video frame. Now lets see what happens when we increase image buffer size by using a higer resultion. We set the intended duration back to 6 ms and run the program at a resolution of 1600x1200 pixels. Note that we have to select a refresh rate of 75 Hz here since our system is not capable of running this resolution at 100 Hz.

   java de.pxlab.pxl.run.ExRun -S 4 -w 1600 -h 1200 -R 75 -D time 

Here is the resulting data file:

6	1154565961.5787	1154566014.8901	53.3114	47.3114
6	1154566334.8813	1154566388.2057	53.3244	47.3244
6	1154566748.1967	1154566801.5248	53.3281	47.3281
6	1154567134.8648	1154567188.1826	53.3178	47.3178
6	1154567521.502	1154567574.8206	53.3186	47.3186
6	1154567934.8147	1154567988.1361	53.3214	47.3214
6	1154568308.1262	1154568361.4516	53.3253	47.3253
6	1154568681.445	1154568734.7695	53.3245	47.3245
6	1154569094.7568	1154569148.0836	53.3268	47.3268
6	1154569468.0736	1154569521.3989	53.3253	47.3253

It shows that now the actual display display durations have been extended to about 53.3 ms which at a refresh rate of 75 Hz corresponds to 4 video frames of 13.3 ms each. The debugging protocol reveals the source of the error:

PresentationManager.showDisplayList(): Creating buffer for Trial.ClearScreen:Pre [0]
ExperimentalDisplayDevice.createMemoryBuffer(): Acceleration is not required.
ExperimentalDisplayDevice.createMemoryBuffer(): Created standard image buffer.
  The buffer is not accelerated.
  The buffer is not volatile.
  Accelerated memory available: 69708 KB
  Remaining accelerated memory: 69708 KB
PresentationManager.showDisplayList(): Creating buffer for Trial.SimpleBar [0]
ExperimentalDisplayDevice.createMemoryBuffer(): Acceleration is required.
ExperimentalDisplayDevice.createMemoryBuffer(): Created volatile image buffer.
  The buffer is accelerated.
  The buffer is true volatile.
  Accelerated memory available: 69708 KB
  Remaining accelerated memory: 62208 KB
PresentationManager.showDisplayList(): Creating buffer for Trial.ClearScreen:Post [0]
ExperimentalDisplayDevice.createMemoryBuffer(): Acceleration is required.
ExperimentalDisplayDevice.createMemoryBuffer(): Created volatile image buffer.
  The buffer is not accelerated.
  The buffer is not volatile.
  Accelerated memory available: 62208 KB
  Remaining accelerated memory: 62208 KB
Start display list:           1154569184

--- Trial.ClearScreen:Pre[0] [M]
Prepare timing group:         1154569220
Image buffer shown: --------> 1154569266
Intended duration:            200000000
Acc. image preloading time:   2.278483
Fixed duration:               193648459
Timing group finished:        1154569462

--- Trial.SimpleBar[0] [M]
Prepare timing group:         1154569462
Preloaded image shown: -----> 1154569468
Intended duration:            6000000
Std. Image preloading time:   46.254571
Fixed duration:               0
Timing group finished:        1154569514

--- Trial.ClearScreen:Post[0] [M]
Prepare timing group:         1154569514
Preloaded image shown: -----> 1154569521
Intended duration:            1000000
Fixed duration:               1000000
Timing group finished:        1154569522

It shows that the system was not able to allocate an accelerated buffer for the ClearScreen:Post object and thus image preloading for the ClearScreen:Post object took about 46 ms as compared to accelerated image preloading for the SimpleBar object of 2.3 ms:

...
Acc. image preloading time:   2.278483
...
Std. Image preloading time:   46.254571
...
which delayed the presentation of the ClearSreen:Post object by that amount of time. Actual image presentation then could only start after the next retrace signal such that the actual duration became about 54 ms.

[Note that there seems to be bug in the underlying Java or DirectX software, whoever is responsible: It reports 62206 KB of free accelerated image memory but refuses to allocate another accelerated image buffer. Also the initial number of 69708 KB available accelerated memory size is false since the system where this was run has only 64 MB of video memory.]

The file VideoFrameDurationLimit02.pxd contains a slightliy modifies version of the previously described file. It creates a random intended duration for the SimpleBar object and then records the actual duration. The following image shows the result for 50 trials under two screen resolutions: 800x600 and 1600x1200 pixels.

It is clearly shown that at the resolution of 800x600 pixels the system is capable of following single frame durations exactly. All actual duration values are the nearest integer multiples of the 10 ms video frame duration. At a resolution of 1600x1200 pixels, however, the lowest valid duration is 54 ms as shown previously. Intended durations above 54 ms again are integer multiples of the video frame duration of 13.3 ms in this case. Thus intended durations larger than 54 ms are valid up to the nearest possible physical limit. Display objects with intended durations of less than 53 ms can not be shown exactly in this mode an this machine.

[Note: The PC used to run these tests has an Intel D875PBZ system board, an Intel Pentium 4 CPU running at 3 GHz, and 1 GB RAM. The graphics system is a Matrox Millenium P650 board with 64 MB RAM, running in a dual screen setting with 1600x1200 pixels per screen at a refresh rate of 75 Hz.]

For comparison the following timinig values have been collected on a different system. This is a PC with an Intel D865GBF system board with an Intel Pentium 4 CPU running at 3 GHz, and 1 GB RAM. The major difference is the graphics system. The D865GBF board has an on board Intel 82865G Graphics processor which shares its graphic memory with CPU RAM. The graphics system runs at 1280x1024 pixel resolution and a refresh rate of 60 Hz. The shared memory feature allows for extreme fast buffer transfers to video memory. Here is part of the debug protocol for an intended presentation duration of 6 ms:

...
--- Trial.SimpleBar[0] [M]
Prepare timing group:         431119
Preloaded image shown: -----> 431133
Intended duration:            6000000
Acc. image preloading time:   0.085347
Fixed duration:               952703
Timing group finished:        431135

--- Trial.ClearScreen:Post[0] [M]
Prepare timing group:         431135
Preloaded image shown: -----> 431150
Intended duration:            1000000
Fixed duration:               1000000
Timing group finished:        431157
...

It shows a display duration of 17 ms (= 431150 - 431133) and an image preload time of 0.085 ms. The corresponding data file is

6	428084.4138	428101.0693	16.6554	10.6554
6	428384.2323	428400.9175	16.6852	10.6852
...
6	431132.8224	431149.5122	16.6898	10.6898

We see an actual duration of 16.6 ms which is exactly a single video frame duration at a refresh rate of 60 Hz. This system is so fast that under any possible condition the display duration limit is less than a single video frame duration.

How Page Flips are Handled

PXLab uses accelerated video memory and optimized page switching methods to achieve fast screen content changes. The actual methods used to switch screen pages, however, depend on several soft- and hardware components of the system we are running on. In general it seems that the underlying Java and operating system software does hardware page flipping only in full screen exclusive mode ('-S4') and uses a bit blitting technique in all other modes. And most graphics system drivers will synchronize page flipping always to the vertical retrace period. This means that in mode '-S4' page flipping will always be synchronized to the vertical retrace while in mode '-S2' it will not. PXLab Display object presentation will be synchronized to the vertical retrace independent of the video mode selected whenever the respective Timer requests that feature and the underlying operating system provides that functionality. Currently only Windows DirectX has an operating system implementation of vertical retrace synchronization. The test file UnsynchronizedVideoFrameDuration01.pxd can be used to check how a system handles video page flips. It creates a display sequence of a ClearScreen object, followed by a vertical bar which is followed by another ClearScreen object. The start of the vertical bar is synchronized to the vertical retrace. The end of the vertical bar is not synchronized. The duration of the vertical bar is set to 4 ms which is less than a video frame duration. Thus the intended optic display should show a vertical bar which starts at the top of the screen window but then is broken at some point such that no complete vertical bar is visible. The vertical bar is shown starting with the retrace and after 4 ms the bar is replaced by a ClearScreen and this should happen while the video beam runs down the screen. This is what actuall is observed when UnsynchronizedVideoFrameDuration01.pxd is run with the following command line, at least on my system:
java de.pxlab.pxl.run.ExRun -S0 -w 800 -h 600 -D time

Here is a section of the data file:

4	1416390897.6629	1416390902.6012	4.9383	0.9383
4	1416391190.9699	1416391195.1108	4.1409	0.1409
...
4	1416393537.5311	1416393541.6642	4.1331	0.1331

It shows that PXLab actually reports a display duration of about 4 ms. The visual appearance is as expected: we see a broken vertical bar. Looking at the debug protocol we also see that accelerated buffers have been allocated and buffer preloading is done extremely fast with about 0.04 ms:

--- Trial.ClearScreen:Pre[0] [M]
Prepare timing group:         1416393322
Image buffer shown: --------> 1416393333
Intended duration:            200000000
Acc. image preloading time:   0.039596
Fixed duration:               195888169
Timing group finished:        1416393529

--- Trial.SimpleBar[0] [M]
Prepare timing group:         1416393529
Preloaded image shown: -----> 1416393538
Intended duration:            4000000
Acc. image preloading time:   0.039629
Fixed duration:               3889775
Timing group finished:        1416393542

--- Trial.ClearScreen:Post[0] [M]
Prepare timing group:         1416393542
Preloaded image shown: -----> 1416393542
Intended duration:            1000000
Fixed duration:               1000000
Timing group finished:        1416393543

The observation becomes unclear, when the command line is changed to

java de.pxlab.pxl.run.ExRun -S0 -w 1280 -h 1024 -D time

In this case the data output is exactly identical to the previous case but the visual information changes: We now see a complete vertical bar. No break appears. What does that mean? It seems that the software only initiates the buffer transfer and returns immediately. Such that the time measured for stimulus duration is misleading.

The same behaviour is observed with full screen exclusive mode in any resolution. Full screen exclusive mode is initiated by using option '-S4'. On my system this always results in a complete vertical bar. The Java display system uses hardware page flipping in full screen exclusive mode. And this seems to be bound to the vertical blanking interval such that screen content changes become effective only at the next vertical retrace.

Video System Display Time Control

The design file Video2SerialSync03.pxd creates an external signal on a serial port control line, shows a single video frame, and then removes the external control line signal. The purpose of this test is to check whether there is a general delay involved when showing visual signals on the screen. Such a delay could possibly be introduced by the graphics controller when making page flips.

The lower line in each image shows the serial control box line. The upper line is the response of a light sensitive transistor fixed to the screen. The delay between the rising edge of the serial control line and the rising edge of the light trace is about 3.5 ms in the upper image and about 13 ms in the lower image. The difference between the two images is that in the upper image the light sensitive transitor was positioned at the top of the screen and in the lower image it was positioned at the bottom of the screen. Screen refresh cycle was set to 100 Hz. Thus the difference between the two images reflects the duration of a single video frame. Most important: There is no frame duration delay between serial line signal and video signal. This means that the graphics hardware does not introduce delays.

These images show a similar setup. The difference to the previous design is that here the serial control line signal is switched off almost immediately after it has been switched on such that it constitutes only a short trigger pulse. The top image shows a single frame (10 ms) video signal and the bottom image shows a video signal of 3 frames duration (30 ms). The light sensitive transistor was positioned at the screen center.

This tests have been run on a PC with an Intel D865GBF system board, 512 MB RAM and a 3.2 GHz Intel Pentium 4 CPU. The graphics system is the on board Intel 82865G graphics controller. It runs at a resolution of 800x600 pixel with 100 Hz refresh rate. The PXLab video mode used is '-S2'. This is a full screen mode which does not use hardware page flipping.

It turnes out that on this system this mode is more reliable than the hardware page flipping mode '-S4'. The following images compare modes '-S2' and '-S4' on the same PC.

The top image shows measuremnts with mode -S2 and the bottom image shows results of the same design file running in mode -S4. We clearly see that the full screen exclusive mode -S4 results in hardware page flips which have a delay of 1 frame. Thus in this case the video signal is exactly one frame delayed against the serial port signal.

Response Time Measurement

In order to control the precision of response time measurement we simulate a subject on a second PC. This PC has a light sensitive switch connected to one of its external control box lines. This line is treated as if it were a response switch connected to a serial port input line. The PC first waits for a 'response' on this line and then waits a fixed number of 205 ms until it switches on an output signal on the external control box connected to the serial port. This signal is treated as a subject response by the first PC. The first PC starts with a black screen. It then switches to a bright screen which is detected by the light sensitive switch and thus triggers the second PC. When the second PC delivers its 'response' the first PC records response time. Here is the resulting data file for the case where the simulated subject has a response time of 205 ms.

5180270.5594	5180479.3859	207.2761	0
5181092.5506	5181301.6209	207.5036	0
5181904.5305	5182114.0639	207.9687	0
5182716.5255	5182924.5819	206.4791	0
5183528.5165	5183737.041	206.9519	0
5184350.5605	5184559.3063	207.1409	0
5185162.5144	5185371.8237	207.6564	0
5185974.5345	5186182.3071	206.1320	0

The mean value is 207 ms. This is 2 ms off the target value which corresponds to less than 1 %. The video signal was synchronized with the vertical retrace in this case and the light sensor was fixed to the top of the screen. One reason for the delay may be that the actual point in time of vertical retrace synchronization currently is the start of the vertical blanking interval. This, however, is not the point in time when the signal actually appears on the screen. The signal only appears on the screen at the beginning of a scan interval which may be some time later. The main point of the above data is the standard deviation. It is only 0.6 ms which seems rather good. Actually part of the constant error and of the standard deviation may of course be due to a 'true' constant error and variability of the simulated subject PC.

The parameter TimeControl of a Display object always contains the exact time when the respective Display object has been shown. The above data table contains the TimeControl values of the video target signal and the signal immediately following it. Computing the difference between the two columns shows that this difference is about 3 ms larger than the value of the ResponseTime parameter. The reason for this delay is that the software needs about 3 ms to switch back to the experiment running thread after it had been waiting for a response event. Whenever a RESPONSE_TIMER is used then the experiment running thread creates and shows the stimulus and then goes into a sleep state and waits for the response event. The response event is detected in the event queue thread and immediately gets its time stamp when it has been detected. Then the event is processed and finally the experiment controlling thread is woke up again to proceed running the experiment. And this thread switch seems to take about 3 ms on our system. The experiment controlling thread then shows the next stimulus and this generates the respective TimeControl data. Thus the actual value of ResponseTime and the difference of successive TimeControl data differ by about 3 ms. The value of ResponseData is, however, the more correct value. Also note that this type of delay does not occur for timers of type CLOCK_TIMER, since in this case PXLab uses an optimized wait method which avoids the thread switch delay.

Sound Signal Timing

When PXLab starts a sound signal it creates a new thread which takes care of playing the sound. In many cases most of the work will be done by the sound card and its driver. Synthetic sound signals always are created in abuffer and played from this buffer by the sound software. The timing question posed here is how the sound player synchronizes to the rest of the display process which is run in the main runtime thread. The design file Sound2Serial03.pxd starts playing a synthetic sound with a duration of 50 ms and immediately after the sound object has initiated the sound player switches on an external control box signal. Thus ideally both the sound signal and the external control box signal should start at almost the same time. Here is the result:

The uper trace in each image is the serial port signal and the lower trace is the audio output signal. We show two variants which have been selected to represent the timing range. In both cases the sound signal has a delay of 20 to 25 ms behind the serial control box signal. Thus although the serial box signal control object follows the sound signal it actually starts before the sound signal. The sound player has a delay of 20 to 25 ms before sound playing actually starts. And there is a considerable variablitiy of 5 ms for this delay.

This test has been run on the same PC as described in the previous section [Intel D865GBF system board, 512 MB RAM, 3.2 GHz Intel Pentium 4 CPU]. It has an on board audio system.

Synchronization to External Signals

The design file Serial2Video02.pxd checks synchronization of a video display to an external trigger signal. It uses an external response box connected to the serial port's control lines. The setup used here, however, has the external response key line connected to a second PC's serial port such that the external trigger can be generated by PXLab running on the second PC (this PC runs the design file external_box_on_off.pxd ). The test PC runs a trial defined in the following way:

    Trial() {
      ClearScreen:Ser() {
        Timer = de.pxlab.pxl.TimerCodes.RESPONSE_TIMER;
      }
      SimpleBar() {
        Timer = de.pxlab.pxl.TimerCodes.VS_CLOCK_TIMER;
        Height = screenHeight();
        Width = 300;
        Duration = 10;
	Color = White;
      }
      ClearScreen:Post() {
        Timer = de.pxlab.pxl.TimerCodes.VS_CLOCK_TIMER;
        Duration = 1;
      }
    }

The ClearScreen:Ser() object waits for a response event. The response event is triggered by the rising edge of the external response box signal. This results from the fact that the external response box has been opened as a response box earlier in the Session display:

    Session() {
      ...
      SerialCommunicationDeviceControl() {
	CommPort = "COM1";
        CommandCode = de.pxlab.pxl.SerialCommunicationDeviceControlCodes.XOPEN;
      }
      ...
    }

Here the SerialCommunicationDeviceControl object gets the XOPEN command to open the connection to the external response box. After this is done the external response box can create response events as any other response device. The response event starts the SimpleBar object whose timer is synchronized to the vertical retrace and has a duration which is 10 ms in the left image and 30 ms in the right image. At a refresh rate of 100 Hz this corresponds to 1 and 3 frames respectively.

The lower trace in each figure is the serial input line which is controlled by the second PC. It sends a signal which triggers the output of the screen stimulus. The upper trace shows the response of a light sensitive transistor fixed to the screen. The left image shows a single frame stimulus and the right image shows a visual stimulus of 3 frames. Both visual stimuli are triggered by the serial box input line. The screen runs at a refresh rate of 100 Hz such that the delay between the two successive video frames is 10 ms. The interesting part is the delay between the serial control box signal and the first video frame. This delay is less than 2 ms. This means that 2 ms after the rise of the external control box signal the first video signal appears on screen. Note that here the external signal is not synchronized to the video refresh cycle. Thus the observed delay has been selected from different samples as beeing one of the smallest observed. It may, however, be possible that even smaller delays can be found. Also note that the light sensitive transistor had been fixed to the top of the screen in order to get the smallest possible delay.

This test has been run on the same PC as described in the previous section [Intel D865GBF system board, 512 MB RAM, 3.2 GHz Intel Pentium 4 CPU, on board Intel 82865G graphics controller, a resolution of 800x600 pixel with 100 Hz refresh rate, PXLab video mode '-S2'].

Time to Start a Movie

The PXLab MediaPlayer display object shows media files including sound and video. Subclasses of MediaPlayerare MediaPlayerOpen, MediaPlayerStart , and MediaPlayerSync which allow a more fine grained control of the media presentation. If exact time control of media playing is necessary then the way to go is to first use MediaPlayerOpen to prepare the media file for playing, then synchronize to a timing event and start media playing with MediaPlayerStart. This is shown by the design file Serial2MediaPlayer.pxd. It first opens the media file and prepares everything in order to start the movie as fast as possible. Then it waits for an external signal and immediately starts the movie after the signal is detected. Finally it waits until the movie is finished. The following image shows the timing. The movie used here has been created frame by frame. It originally contained 5 frames with full frame images of the following sequence: black, white, black, white, black. The MediaPlayerOpen object prepares the movie and presents the first image of the movie as a static image on the screen. After the serial input signal arrives the movie starts to play with the first image.

The lower trace of the image shows the serial input signal and the upper trace shows the response of a light sensitive transistor at the screen center. Video refresh rate is set to 100 Hz. The movie is played at a frame rate of 25 Hz which corresponds to an image duration of 40 ms. This is exactly what is seen for the 2nd and 4th image of the movie. Each image is presented with 4 video frames. The blank intervals in between are the black movie images. Since the first black image precedes the second movie image we observe a delay of about 21 ms between the rising edge of the serial input signal and the start of the first movie frame. Note, however, that neither the trigger signal nor the start of the movie are synchronized to the vertical retrace. At a refresh rate of 100 Hz this implicitly generates an uncertainty of 10 ms.

Suggestions

What do we learn from these results?

Whenever short video display durations are required one should use clock timers which are synchronized to the vertical retrace. This is achieved by setting Timer to de.pxlab.pxl.TimerCodes.VS_CLOCK_TIMER.
Video mode selection is critical and depends on the graphics hardware used.
A general advice is to use full screen exclusive mode ('-S4') on systems which have 'slow' graphics systems. 'Slow' refers to the time it takes to copy data from CPU RAM to video RAM. On a fast system it seems better to use an ordinary full screen mode ('-S2') since this will provide more accelerated memory buffers and the timing seems to be more reliable since there is better timing control by PXLab. In full screen exclusive mode the page flipping seems to be driven by graphics hardware such that PXLab's timing becomes more unreliable. This uncertainty, however, remains within the duration of a single video frame.

When using mode '-S2' it is not possible to modify the pixel resolution and the refresh rate from the command line but these parameters have to be set on the operating system level.

Hardware Selection
We have tested only a very limited range of hardware constellations. Originally we have selected the Matrox Parhelia and Matrox Millenium P650 boards because of their superior RAMDAC output signal quality. Our timing tests show that these boards are somewhat slow when copying data from CPU RAM to video RAM. Copies within video RAM are OK. Very good results with respect to timing and memory transfers have been observed with the onboard graphics controllers of the latest Intel system board D865GBF. This board shares CPU RAM and video RAM which seems to result in very fast transfers to video RAM. RAM sharing may slow down CPU memory access but at the current CPU and memory speeds this seems to be negligible.