Re: reaction time measures

[Bob Masta <audio@xxxxxxxxxxx>]

On 10 Jun 2007 at 16:30, Pawel Kusmierek wrote:

> > On 9 Jun 2007 at 14:48, Pawel Kusmierek wrote:
> 
> > > I think that you could do the same with visual stimuli by attaching a
> > > sensor (photoresistor, photodiode) to an area somewhere near the
> > > border of your screen and displaying a marker in this area along with
> > > your stimulus. The signal from the sensor could go to your soundcard's
> > > input (via an appropriate circuit) for recording in one channel, and
> > > behavioral responses would be recorded on the other channel. This
> > > requires some external hardware, but I believe it could be small,
> > > especially if you use a USB port to power it.
> >
> > Interesting idea!    Sort of like an old "light pen", but at a fixed location.
> > The circuitry would be pretty simple, needing only to stretch the
> > short dot-clock pulse to something suitable for the sound card.
> > (Or with a slow-responding photoresistor, maybe even this wouldn't
> > be needed.)
> 
> I thought this would not be necessary, (but I do not know what a "dot
> clock pulse" is). I thought that usually LCDs (we are talking about a
> laptop, right?) are accused of being too slow rather than too fast,
> and even if the picture (and the marker) was displayed for a single
> frame, the signal would last a few ms. The other thing is that the
> marker might be left on after the picture (stimulus) is turned off, if
> necessary.  Is there anything about LCD technology that would make the
> marker last for a too short time to be detected by a soundcard?

Actually, I was thinking of CRTs... you are correct that LCDs would be
much slower.  The dot clock I referred to is essentially the time allocated
to draw a single pixel on the CRT face.  As the beam sweeps across,
it is modulated at this rate to draw all the pixels in a horizontal line.
The assumption here is that the phosphors decay fairly quickly so that
the next time the same pixel is drawn, there will be a new pulse.
I have not looked at the photo-response of an LCD, but they are supposed
to be in the several millisecond range, so that should be fine as-is.

> Another nice way to make sure that a possibly very short input signal
> won't be missed by the input is to use a flip-flop circuit which keeps
> the input high until the computer reads it. Then the computer clears
> the circuit and may receive another input.  This has been used by the
> Cortex spike recording program (
> http://www.cortex.salk.edu/CortexCircuit.php ), and I am using this
> solution in my program. This is probably again more suitable for TTL
> I/O than for soundcard-based I/O.
 
It might even be feasible to tap into the monitor signals directly.
It should be fairly easy to detect a vertical retrace pulse, and start
a delay to get to the desired part of the screen, then grab the signal
at that instant to read a particular pixel or short line segment.  A
simple comparator (and pulse stretcher) would do the job there.
But I like your original idea the best... simple and direct.
 
> > I have not tested any true multichannel input cards.  Note that the vast
> > majority of "multichannel" cards (5.1, 7.1, etc) are referring to the
> > outputs... they still have only stereo inputs.  However, a few "semi-pro" and
> > "pro" cards have 4 (or more) inputs, though I believe they require special
> > software.
> 
> I referred to the semi-pro cards, like M-Audio delta series, not the
> x.1 things. I have no direct experience with multichannel cards, so I
> might get wrong impression from reading their manuals
> 
> > Nonetheless, I am certain that they retain perfect sync between
> > channels.  I have never heard of a card that appears as multiple stereo
> > inputs; it would be the same as having multiple stereo cards.
> 
> Except these "stereo" cards would (or should) be perfectly
> synchronized, because they use the same clock. Still don't how to
> handle this in windows without losing the relative timing between the
> pairs.  I am pretty sure that audio recording programs can do this -
> so it should be possible.  I got the "appearing as multiple stereo
> cards" idea from manuals like
> http://www.m-audio.com/images/global/manuals/070208_Delta1010_UG_EN01.pdf
> (see p. 12 there).

In reviewing this page, I believe it simply refers to names of lines;
there is no reason they should not be all synchronized together, and
in fact for a pro card like this it would be unthinkable if they were not.
In Windows, you would have to use WAVE_FORMAT_EXTENSIBLE
in order to have access to all the lines, assuming this card supports
that.  (I haven't read the rest of the manual to find out, yet.)   I haven't
messed around with DirectSound yet, but I believe that provides an
alternative access method, which would be preferred over the old
Wave functions since Windows seems to be deprecating them.
 
> > One problem is that Windows doesn't allow for easy dealing with the
> > parallel port lines as individual signals, like in the good old DOS days.
> > Win9x allowed direct I/O to the port, but later versions require special
> > ring-0 drivers.  There will still be all the usual latencies in reading the
> > port, up to several milliseconds, so the experiment would have to
> > be such that there was no ambiguity about which TTL data went
> > with which sound card event.
> 
> Yes, you are right. Do you have any knowledge about latencies caused
> by using such drivers (in addition to typical problems of timing under
> Windows)? I am using http://www.logix4u.net/inpout32.htm and the time
> between port checks is typically less than 50 us for about 20% of
> checks, less than 1 ms for 90 % of checks and less than 2 ms for 100%
> of checks. This would imply the the delay introduced by using the
> driver is less than 50 us, which would be negligible for me. But one
> can imagine that the driver uses a buffer and returns "old" data. This
> seems unlikely for me.  Also, the timing of the data I am getting with
> this system seem to make sense - latency of neural response to sound
> in the auditory cortex is>= 10 ms.

I don't think the ring 0 driver adds any particular latency by itself.  You
would still be subject to normal Windows latencies.  Your characterization
of these latencies seems to match what I have seen, except that I would
not want to bet on 100% being under 2 msec.  Since Windows is not a
real-time operating system, they don't guarantee the limit... and I think it
can be over 10 msec on rare occasions, depending on what else is going
on.

> 
> > For new designs, the printer port (and its attendant latency problems) could be
> > avoided by putting more processing into the audio inputs.  Response buttons
> > could provide different DC levels.  Each button could produce a short pulse of
> > a specified level, with different buttons having levels weighted in 1, 2, 4
> > binary fashion.  Or, each could produce a same-level pulse but with
> > different binary-weighted duration.  Either way, you could always recover
> > the exact timing of the switch closures (pulse onsets) at sample-rate
> > resolution, even if multiple button presses overlapped in time.
> 
> I am a little afraid that this may not work so well in real world,
> where sound card's input won't hold a DC signal. So the picture would
> be confounded by decays - have you tried this solution?

After I wrote that, I realized that the binary pulse length scheme could
be confounded by just the precisely "wrong" times of arrival, but I still like 
the original binary weighted level scheme.

I haven't actually tried the summed binary weightings, but I see no reason
why it won't work, given the right software to extract the data.  It is true
that the card is AC coupled, but if you apply a DC step, the spike that
gets recorded does go to the proper level before it starts to decay as the
input capacitor charges up.  (You have to make sure that you are not
clipping the input range, however.)  The software would have to look for 
vertical jumps, then read the voltage at the top of the step and compare to the
voltage at the start of the step.  Messy, but I think possible.

With a bit more hardware at the switches, each button press could be
converted into a biphasic pulse (say, 1 msec per phase) with a binary-weighted
amplitude.  This would maintain the average zero level and hence avoid
decay issues.  This is probably what I would do if I were building a single
setup, but if I were to offer something for others to put together I'd probably
want to do it all in software to minimize the need for special hardware
circuitry.

Best regards,

Bob Masta
 
            D A Q A R T A
Data AcQuisition And Real-Time Analysis
           www.daqarta.com
Scope, Spectrum, Spectrogram, Signal Generator
    Science with your sound card!