Voice response times ending in same number

[I][edited from support email][/I]
The voice RTs I get end almost always with the numbers 9/0/8, without variability. What does that mean?

I expect this is likely an issue of timing resolution on your system. e.g., on any given system it take X amount of time to process the sound coming in and to check it to see if the amplitude is high enough to qualify as an RT. This cycle repeats over and over at a very fast rate. When you have final digits in the RT that seem to repeat, that usually indicates that the standard cycle is reliably occurring in "chunks", e.g., every 10ms rather than every millisecond. The best way to ensure the validity of your voice RTs is to check a random sample of them manually. This can be done fairly easily with a freeware program called [URL="http://audacity.sourceforge.net/"]Audacity[/URL] which allows you to look at the amplitude of wave files on a millisecond scale. If you want to send me half a dozen of your .wav files, I can show you. Doing so, I expect, will show that you have a reliable ~10ms timing resolution on your RT detection.

thankyou. I appreciate it a lot. I'm attaching 5 wav files.
Rona

Take a look at the attached images. The first is what 1.wav looks like if you open it up in Audacity (see above). Where the amplitude jumps is where the sound is occurring. In the second image, you see I've zoomed in on the area where it really picks up, i.e., around 360ms. The sensitivity you use in the setup will affect the exact RT you get but with average settings, I expect you would get an RT of around 355-360ms on this trial.

The second is tricky because it seems to have two peaks (around 490ms and then again at just under 590ms).

The third is tricky because it is a [I]very [/I]gradual increase in amplitude. Your RT in this case will very much affected by your sensitivity setting. Seems like you could accept an RT here as low as 280ms or as high as 335ms. If you actually listen to the clip and follow the cursor as it plays, you can see the correct RT is probably around 280ms. Note that you can highlight any given range and play just that part in order to judge whether a legitimate response is occurring at that point.

The fourth looks to be around 425ms.

The fifth looks to be around 597ms.

Does that help?

-Blair

yes. thankyou, it does...unfortunetly as I was comparing the wav files to the RT's on the log files I've noticed that on some occasions (not few) the data didn't match. for instance in the log file the RT written was of 180ms whereas on the matching wav file the recording starts at around 400ms. no interference before. this happened with different lenghts. I imagine that it indicates that for some reason the data didn't copy properly to the log file.
I'm assuming the problem is with the laptop, maybe with definitions on it.
Did you encounter this problem before?
thankyou again,
Rona

Can I see the input file, log file and resulting .wav file for that trial?

of course, I'm attaching the log file, the input file and some wav files.
thankyou
Rona

hello again,
I ran a check with the dxdiag command, and in the directx diagnostical -direct sound test appeared the message: your sound card does not support hardware buffering. sounds will only play from software buffers.
it's an IBM R51 and the sound card is sound max integrated visual audio.
could that be the problem causing the distorted log files?
Rona

Could be. Easiest way to check would be to connect an external sound card--Creative makes some that work with laptops via USB.