I have been struggling with a timing issue with Inquisit for some time now, in fact I posted a question about it some time ago, related to Inquisit 2: http://www.millisecond.com/forums/Topic2348.aspx. I'm now testing out Inquisit 3 with a view to upgrading and am finding the same issue.
The issue is a consistent timing error, such that the total length of each trial is slightly longer than it should be. Sean's response to my original post was to suggest inserting pre and post-trial pauses to give Inquisit time to wrap the trial up, however this doesn't seem to help.
I've been coping with the issue by deliberately setting the trial duration lower than it 'should' be, so if I want a trial to last for 1000 ms, I actually set the trial duration to, say, 9900 ms. However, fixing the issue is not as simple as having a simple rule of "knock off 100ms from the duration of every trial" - the error seems to be somewhat capricious depending on what kind of stimuli (and how many) are being presented, although it's generally consistent across trials of the same type. Fixing the error and getting the timing I want therefore requires a fair bit of tedious data-logging with external hardware, or sitting there with a stopwatch timing the total length of the program and iteratively knocking off or adding a few milliseconds to the trial durations in order to get the total length as accurate as possible.
To illustrate this I've written a very simple example program. This presents shape stimuli (a green circle, and a black circle to 'erase' the green one) on every trial, and the trial duration has been set at 1000ms. There are 60 trials, so the total length of the program should be 1 minute. In fact, the total length of the program is approximately 1 minute and 3 seconds. Inquisit is therefore adding on approximately 50ms (or three frames) to each trial. Changing the pre and post trial pauses from 100 ms to 0 ms has no effect. Inquisit logs the trial duration in the data file as whatever is specified in the script, which is unhelpful.
Apologies for the length of this post, but I now have several queries:
1. Why does this happen? As I understand it, Inquisit uses the system timer, which should have sub-microsecond resolution. Given the timer's resolution it seems very odd that such a large error occurs.
2. How can I ensure that the timings I enter into the script are what I actually get when the script executes? Is there some little trick I'm missing here? I've tried controlling the length of trials using the timeout feature as well, but that doesn't seem to help. As noted before, Sean's original suggestion of inserting a post-trial pause doesn't seem to help.
3. Are the values for trialduration which are logged in the data file actually measured as the program executes, or are they just copied from the relevant parts of the script? I'm guessing the latter, since they seem to be inaccurate.
4. Has anyone else seen behaviour like this?
5. Can some kind person help me out by trying to reproduce the error using the attached script? The magnitude of the error does seem to be somewhat hardware dependent, but there's always some kind of lag. I generally use up-to-date hardware (dual core processer, lots of RAM, Windows XP, things like anti-virus disabled) for running my programs.
Many thanks for any help you can give me with this. I've been using Inquisit for years and genuinely adore it, but if I can't solve this problem I'll have to start using something else. Plus, I've just embarrassed myself in front of my supervisor by running a load of fMRI scans with crappy timing. :o(