Timing issue in Inquisit 2.0

Back

Timing issue in Inquisit 2.0

Author	Message
matt2004	matt2004 posted 16 Years Ago Topic Details Share Topic
Group: Forum Members Posts: 11, Visits: 1	Hi there Inquisit wizards, I have a timing issue that has been bugging me for some time. I have attached a very simple example script which illustrates the problem. The issue is with the / trialduration command in the trial element. I need my trials to be a specified duration, with as minimal an error as possible. The attached program presents a single word on the screen for two seconds, and this is repeated for 80 trials. This should give a total running time for the program of 140 seconds (80 trials x 2 secs). Trial duration is controlled by /trialduration = 2000. The problem is, there is a consistent error such that the program always runs approximately 3.5 seconds long (timed 'by hand' with a stopwatch). It appears that Inquisit is adding approximately 35-40 ms to each trial's duration. The logged data simply say that each trial's duration is 2000 ms. It doesn't seem to matter how long the trial is i.e. if I specify a trial length of 1 second or 10 seconds, there always seems to be a bit extra added to every trial. 35-40 ms doesn't seem like much, but over a large number of trials it adds up. Previously I've been coping with this by simply specifying trial length to be 1960 ms, and this appears to give trials of approximately 2000 ms, however this has always made me somewhat nervous as I'm not really sure where the error is coming from and whether it really is consistent across trials. I know that specifying exact timings is difficult because of refresh rates etc. etc. but I think the error due to Inquisit waiting for the next screen refresh should be less than this, yes? I've tried this on several different computers, running both Vista and XP, and changed all the parameters I can think of in the program, and it seems to be consistent and reproducible. I've now run into a situation where I really do need absolutely precise timing information (for synchronisation with a MEG machine, which can sample at very high temporal resolutions) so would appreciate anybody's thoughts on this. I know Inquisit is very good at, for instance, presenting items for a single screen refresh etc. so I'm surprised that this error seems so pervasive. Apologies for the length of this post, and many thanks for your help with this. Regards, Matt Wall (Royal Holloway, UK). Attachments MW_exp_bare_bones.exp (895 views, 434 bytes)
	Reply Like 84
matt2004	matt2004 posted 16 Years Ago ANSWER Post Details Share Post
Group: Forum Members Posts: 11, Visits: 1	Really? Nobody else has noticed anything similar or has a solution? Or have you all just gone home early for christmas? ;o) If anyone has any input at all, I would really appreciate it. Many thanks, M.
	Reply Like 86
seandr	seandr posted 16 Years Ago ANSWER Post Details Share Post
Group: Administrators Posts: 1.3K, Visits: 5.6K	Hi Matt, Christmas hasn't started for me yet. There are a few things you should try to get rid of the inter-trial lag that you are seeing: 1) Download and install the latest Inquisit 2.x update, which is 2.0.61004.7. This update has some optimizations in it that allow you to take advantage of the following suggestion. 2) Add a short posttrialpause to your trial, which gives Inquisit time to wrap up the trial (e.g., deallocate stimuli, compute statistics, record the trial data, etc). For example, let's say your trialduration is 2000 ms and your posttrial pause is 30 ms. Exactly 1970 ms into the trial, Inquisit will stop polling for a response and will use the remaining 30 ms to wrap things up. Give these two suggestions a try, and let me know if you still see any lags. -Sean
	Reply Like 97
matt2004	matt2004 posted 16 Years Ago ANSWER Post Details Share Post
Group: Forum Members Posts: 11, Visits: 1	Thanks Sean, I'll give your suggestions a try and report back. M.
	Reply Like 110
Chris	Chris posted 14 Years Ago ANSWER Post Details Share Post
Group: Forum Members Posts: 1, Visits: 1	Hi Sean, I got a similar problem with a paradigm I programmed for an fmri study. The trials were exactly 33ms too long which added up to an unacceptable time lag. On my personal laptop, I could solve this by inserting a posttrialpause as you proposed. The problem is that this posttrialpause does not work as expected on our fmri laptop which runs an earlier version of Inquisit 2.0. I suspect an update might solve this but still hesitate as I would like to know what exactly that update does to Inquisit (in general, we agreed not to change anything with the program on that laptop). Could you explain what is behind that update? Or is there another way to optimize trial times without updating? Best regards Chris
	Reply Like 88