Re: [Pebl-list] keyboard latency and vertical refresh syncing

[Shane T. M. <stm...@in...>]

Dirk,

I thought I responded this weekend, but the message seems to have
disappeared, so I'll re-send just in case you didn't get my reply

There are at least two issues related to keyboard latency.  First, there
are physical, mechanical, and IO aspects that may introduce all types of
latencies that we know little about.  This is fundamental to the
interface, and suggests that keyboards aren't great input devices for
collecting latency data at a fine-grain level.  The second is the
software systems that keep track of and queue what buttons have been
pressed.  The cross-platform library I use handles this by hooking in to
different OS subsystems.  On some OSes (e.g., on linux under X-windows),
these input/event systems run as separate threads, meaning that there
system needs to switch between two high-priority threads to read in
input, which usually happens at a rate no faster than 10ms (a "jiffy"),
which essentially introduces a 5 ms delay and a uniform 10ms randomness
to latencies.  I'm not certain what low-level input systems are used on
windows, although it is probably possible to hook into the directinput
api to reduce this extra noise.  It would be possible to write new
device 'drivers' that work in PEBL on the primitive IO channels,
especially custom devices, but if you care about latencies like this,
you shouldn't be using windows in the first place--you need a true
real-time kernel.  For my work I haven't needed to address any of this
yet (but it is planned), and I would guess that the mechanical error
involved in pushing a key swamps any of the software latencies.

As for syncing to the vertical refresh, when operating in fullscreen
mode, depending on the capabilities of your video card, PEBL will
operate in double-buffering mode, swapping buffers between syncs and
'blocking' operation until the next buffer frees up.  This enables you
to have pretty good control over the number of refreshes a stimulus is
presented for.  You first need to issue several "Draw()" commands to
prime the pump; then draw the stimulus for how many refresh cycles you
choose, hide it and draw again.  Using this method, I have gotten pretty
good consistency, and you can detect when you blow it (usually because
the OS switches to some other task and doesn't come back until its too
late.  Without a bunch of other processes running, this rarely happens).
I've used this technique to get consistent presentation durations of
stimuli less than 50 ms.

There are a couple demo scripts that you might want to check out to see
how your system will perform.  One is demo/timing.pbl, the other is
RSVP.pbl.  On windows, the output is saved to stdout.txt. Let me know if
you have any other questions.


Stm...

On Sat, 2005-10-22 at 05:42 -0700, d j wrote:
> Hi,
> 
> I just stumbled upon Pebl and after reading the
> release notes and the docs, I wonder what the keyboard
> (reaction time)  latency of Pebl is. The release notes
> have a warning saying it isn't particularly good, but
> it is unclear to me whether this issue has been
> solved. 
> 
> Similarly, can one synchronize displays with the
> vertical refresh? I would only need this on windows,
> but a portable solution would be great.
> 
> Thanks,
> Dirk