The 16ms is for USB in legacy mode, where the BIOS does the USB stack handling and then provides the keyboard input via interrupt 60h to the OS.This is NOT how a USB keyboard should be attached to any OS, and it hasn't been for at least a decade. Modern OSes have native keyboard drivers which integrate USB keyboards like any other USB device and speak to them directly, thereby bypassing that BIOS logic that introduces the delay. Such a driver is then capable of receiving key input with the delay depending on the USB bus delay. That is way shorter than 16ms, but also kind of hard to determine, because with USB being a host-controlled and shared interface, it basically depends on a) whether there is any other device also communicating and b) on the rate by which the host polls the device for new data.
When coming to choose a mouse, people like to talk about its DPI and polling rate. Especially for gamers, artists, and designers, for whom the mouse’s high precision and fast reaction time matter a lot. Since some people know little about DPI, I will have a brief introduction about it before I introduce how to check your mouse DPI.
As far as I know, the latter is configurable (by the device and/or the driver, I'm unsure about that) within certain intervals, and it is possible to poll a keyboard at 1000Hz or even faster, so we're back at a theoretical delay of about 1ms - however, this time that's for the entire byte sequence belonging to a key press/release, not just for one byte as with the PS/2 keyboard, so this delay can directly be translated to keys pressed - no scancode sequences of differing length to account for. Debouncing does add latency how much is dependent on the switch and matrix type as well as the controller.Debouncing isn't limited to keyboards this is a concept in electronic switching.The method of debouncing (software, hardware or both) as well as the 'debounce' window which can be set beyond a certain base limit to an arbitrary value has an impact on latency.' Switches with high actuation point will have inherently lower latency (measured from the start of the keypress).
Check deskthority wiki for the numbers, they should have most mainstream switches listed.Benchmarking the time from switch activation to the computer being aware of the input should be doable (i.e. Ignoring display latency and most of the software stack), alas no tech reviewers I know of do it.
So no easy way for a consumer to compare products. IIRC someone measured the Wooting One to have 4ms of latency. It does have a switch with adjustable actuation point (not so useful if you get the clicky version, since you cant adjust the tactile bump and click).Edit: By high actuation point I mean farther from the board, it's usually specified from the start of the key travel, so lower numbers. In the old days of scan codes the left hand side of the keyboard had (in general) shorter keycodes than the right hand side, so could accomodate more keys being pressed.People started playing fps with the big keypad, but you'd often run into issues where you could only use 2 or 3 keys at a time.Several games such as Duke Nukem etc came with utilities in which you could check if your specific keys would lock the keyboard; after that the default movement keys switched to wasd. For myself I preferred to use 1 finger per key, so I switched to escf. 1ms latency, you say?
With a speed of sound of 340m/s, this corresponds to distance between loudspeaker and ear of 0.34m. So, anything except headphones will add more than 1ms of latency.I get that the rhythmic nature of music enables precision at the scale of a few ms because musicians can anticipate these moments in time (reaction time does not apply). But I'm baffled by claims of sensitivity to delays less than about 10ms because these are near or even over the limits of acoustics. For example, when you do the math, you'll see that it is basically impossible for a large enough orchestra to play perfectly in sync.
But a good orchestra can give the impression of a precise performance despite that. This can only mean that the human hearing is less precise than what people claim. The important point is that there are massive delays between these steps:1. Your brain wants to move a muscle2. The muscle moves3. The effect of the move is processed by your brainAnd still you think stuff happens instantly and you can hit a beat etc.
Our brain just adapts to the latency and removes it from our perception. It it thus not a big deal if you add a little bit of latency between step two and three.
As long as that latency is constant, our brain just adapts.This is of course only true if there are no reference points with lower latency. If you drag an item across a smartphone, we notice tiny latencies, because our finger moves before the icon – something we can easily see. As far as listening to music and determining there is something wrong with it because you noticed a 5ms difference, I find that hard to believe.However, when given samples of audio with no delay and a 5ms delay.
I, with no special talent and no musical training, was able to start accurately identifying the delayed audio almost every time after a few minutes of practice.The difference isn't imperceptible when it comes to a single noise when we are specifically told to look for it, but I would bet that its imperceptible when it comes to just randomly listening to music.
Hi Nicolas,On Wed, Jan 20, 2016 at 12:01 AM, Nicolas McNair wrote: Does Psychopy support USB polling at 1000Hz (either via psychopy.event or psychopy.iohub) or does it use the default 125Hz?as far as I know, the polling rate has to be set by the respective USBdriver and cannot be easily altered from user space. In terms of checking input values, it simply emulates a keyboard press ('a', 's', 'd', and 'f' in the case of our 4-button response pads) so it doesn't actually need any special code to use it as such - but this will default to whatever Psychopy uses for polling a (USB) keyboard. Is that fixed to whatever the OS defaults to, Jon?
I.e., I have a vague awareness that it is possible to change this (in Windows at least) via some registry hack or through various drivers floating around for gamers. If that worked, would that also result in psychopy adopting a higher polling rate? Or would I still need to code that specifically? Hi Nicolas,On Fri, Jan 22, 2016 at 7:05 AM, Nicolas McNair wrote: In terms of checking input values, it simply emulates a keyboard press ('a', 's', 'd', and 'f' in the case of our 4-button response pads) so it doesn't actually need any special code to use it as such - but this will default to whatever Psychopy uses for polling a (USB) keyboard. Is that fixed to whatever the OS defaults to, Jon? I.e., I have a vague awareness that it is possible to change this (in Windows at least) via some registry hack or through various drivers floating around for gamers. If that worked, would that also result in psychopy adopting a higher polling rate?
Or would I still need to code that specifically?yes, you could try one of those 'gaming mouse' driver hacks, althoughI would not really recommend it, since these drivers are usuallyunsigned and you would have to put Windows into Test Mode toinstall/use these drivers; it's all kind of hackish and potentiallycreates security risks.If you decide to take this approach:Since it's the OS USB driver itself that will acquire the response paddata and pump it into the keyboard buffer, I reckon you would not needto change anything about PsychoPy's standard keyboard devices. Youwill definitely have to either A) poll the device yourself viapsychopy.event.getKeys (and possibly a while loop); B) have PsychoPypoll it via psychopy.event.waitKeys; or C) you could try to useioHub's keyboard device to get non-blocking behavior.
As a side note, they do also output a TTL pulse which would provide highly accurate timing of keypresses. But that results in a slightly more complicated set-up than I'd prefer - at least for some of the situations I'm hoping to use it in.I personally would pick this approach. But it requires additional dataacquisition hardware and is not as convenient as simply using ioHub orpsychopy.event keyboard polling.Cheers,RichardJon22.01.16 03:19. Sorry for the late reply.
According the Black Box people, the response pads request high speed polling from the OS when plugged in (USB 2.0 or higher). So they said as long as PsychoPy wasn't interfering in some way, it should be possible to poll at 1000Hz.
I went ahead and tested this using a CRT monitor/PC (running Windows 7) set-up that I know, via independent testing, reports 100% accurate timing for visual stimulus presentation. I just used a simple PsychoPy script that recorded reaction times to a white screen flash across a number of trials. The response pad was connected to the stimulus presentation computer via USB and to the Black Box Toolkit (BBTK) via its high-speed serial connection (which provides sub-millisecond timing). The BBTK was also recording the onset of the flash via photodiode. Comparing the reported response pad RTs on the stimulus presentation computer to those on the BBTK, I get differences across all the trials of less than a millisecond. So it looks like using the Black Box response pads with PsychoPy can provide millisecond timing even when just connected via USB only!
Also, this was just using the waitKeys function from psychopy.event. I haven't gotten around to testing iohub yet, but I'm guessing it should be the same. Nick,Thanks for the useful info.
That means the communication side isworking perfectly, which is great to hear.So, the remaining issue is around how often the box is check. Ithink you'll find that when you check using the default option ofone check per screen refresh you'll get some timing variabilityassociated with that, due to the fact that the screen refresh isevery 16.66ms (at 60hz). I tend to run experiments where stimuli remain on the screen until subjects respond or the stimuli is displayed shorter than any possible reaction time, so yeah I usually just have a screen flip followed by waitkeys.
We did some more testing and found that (unexpectedly and bizarrely) iohub actually produces worse times than the event module in this situation. We've tested it using the waitforkeys and getpresses keyboard functions from iohub, and both report differences from the 'true' reaction time of between 3 and 15ms.
Here's a snapshot from both. To unsubscribe from this group and stop receiving emails from it,send an email to.To post to this group, send email to.To view this discussion on the web visit.For more options, visit.-Jonathan PeirceUniversity of NottinghamThis message and any attachment are intended solely for the addresseeand may contain confidential information. If you have received thismessage in error, please send it back to me, and immediately delete it.Please do not use, copy or disclose the information contained in thismessage or in any attachment. Any views or opinions expressed by theauthor of this email do not necessarily reflect the views of theUniversity of Nottingham.This message has been checked for viruses but the contents of anattachment may still contain software viruses which could damage yourcomputer system, you are advised to perform your own checks. Emailcommunications with the University of Nottingham may be monitored aspermitted by UK legislation.Marius Mather31.01.16 18:49.
I've attached the simple script we were using to check iohub's keyboard event timing. All it does is set the screen to white at the start of the trial and wait for a keypress (currently it checks A, S, D, F and spacebar, since the usb response pad has its 4 buttons mapped to ASDF). If anyone is able to suggest improvements that might improve the timing accuracy, please do. Is there any better way to calculate the RT than running Computer.getTime right after the first flip of the white display, then subtracting that from the event.time of the events returned by iohub's keyboard.getPresses function? Unless iohub's clock is somehow out of sync with psychopy's, this should be the way to calculate the RT, no? Even then I'm not sure if that's the problem, since we've also tried getting the timestamp from iohub just after the flip like WINDOW.flip; trialstarttime = Computer.getTime, with the same results. Since iohub's data collection is running on a separate thread I can't see where the code would be getting blocked by a screen refresh, but there may be something I'm missing.
If there are some unadvertised methods in the iohub classes that would allow me to have a look at the sync between the iohub clock and the psychopy.core clock, I could have a look at that as well. As an aside, my memory was that the default iohub polling rate for the keyboard / mouse on Windows was set to 1 msec, not 10 msec, so I was a little surprised to see that myself when I checked today. Looking at the change history for that file, by a commit I made. Then in t that changed the default kb/mouse polling rate to 10 msec. I do not recall if there was some 'logic' behind me making this change, or if it was an unintentional change left over from some testing I was doing during development. Regardless, it is what it is now, which is 10 msec by default. We are getting the 'true' reaction times from an external testing device (the BlackBox) that measures the time of the screen flip via a photodiode and the key press (from the response pad) via a high speed serial connection.
We have previously tested this particular computer/CRT set-up and found that there is essentially no delay between when the computer records the flip command and when the it is actually drawn on the monitor. The response pads are also connected to the computer via USB, simulating a keyboard. We then compare the time of the keypress to the monitor draw (the RT) as recorded by the computer to that of the BlackBox. The times I've reported are the differences between what the computer has recorded as the RT and what the BlackBox has recorded as the RT. The psychopy.event RTs were a millisecond or less different from the BlackBox RTs. The iohub times were all longer by the given amounts.
As expected, iohub timestamps the same keyboard input earlier than psychopy.event because iohub still processing keyboard events when the experiment process is in a win.flip induced blocked state. The time difference between the two timestamps will vary each time you run it if you are manually making button responses, but should always be less than the retrace interval of your video card. Running it a few times now, I have seen differences as small as 0.6 msec and as large as 12.5 msec (my monitor is running at 60 Hz).This is also the same as what was found in the similar test condition in the posting I linked to yesterday. # You may need to be running in an admin account for this to work.pucount = Computer. GetProcessingUnitCount # Assuming you have a 4 core cpu if computer reports 4 cores# then there is no hypertheading. If 8 cores are reported, then# hyperthreading is enabled.if pucount 4:#try using the second core for psychopy and the third for iohub.psychocores = 1,iohubcores = 2,elif pucount 8:# If there is hyperthreading, then set each# hthread for the relevent core.psychocores = 2, 3 iohubcores = 4, 5 else:raise ValueError ( 'Reported core count!= 4 or 8:%d'% pucount )Computer. SetProcessAffinities ( psychocores, iohubcores )print 'psycho, iohub proc affinities:', Computer.
Cpuaffinity , Computer. PS: Another reason I do not think the issue is related to iohub causing 'issues with.event vs.iohub kb event time stamps' is because I tested the full end to end delay between when a keyboard event actually happens and when the event is time stamped by both.iohub and.event. I tested this using a standard keyboard as well as an usb device that, like the BB usb response pad, can be programmed to generate hid keyboard events extremely quickly following an event on the keyboard emulating device. I posted it before, but here is a link to the thread that describes the test and results in detail.
Adding the code related to examining cores & affinities reported 8 cores. The affinities at the beginning for psychopy and iohub were 0,1,2,3,4,5,6,7. After forcing windows to use different cores, the affinities were 2,3 for psychopy and 4,5 for iohub. This still resulted in timing errors.4. What happens if you run the test script as you would normally (so no iohub) but first start a separate python script This did not make a difference to the output5.
Can you run the psychopydemoscoder timingtimeByFrames.py demo? Here's the results when run as is.
when you run timingtim eByFrames it reports no dropped frames and low interframe interval variance when iohub is running and when it is not. So iohub is not affecting inter frame intervals when using that test.
when you run the your test script and get both.event and.iohub kb event times for each trial response, they are the same (within 0.5 msec). when you run 2) without iohub you get BBTK RT vs psychopy RT differences. Why in the test script are the.event and.iohub kb event times the same, but the calculated RT by BBTK vs psychopy different? The most likely answer would seem to be that iohub is somehow effecting the times returned by win.flip by not the.event timestamping. This fits the data, but seems odd. If the suggested answer to 1) is correct, the why does iohub not affect the timeByFrames script results at all. If the BBTK is measuring the actual RT, and.
you get. As an aside, my memory was that the default iohub polling rate for the keyboard / mouse on Windows was set to 1 msec, not 10 msec, so I was a little surprised to see that myself when I checked today. Looking at the change history for that file, by a commit I made. Then in t that changed the default kb/mouse polling rate to 10 msec. I do not recall if there was some 'logic' behind me making this change, or if it was an unintentional change left over from some testing I was doing during development.
Regardless, it is what it is now, which is 10 msec by default. To summarize the results you are finding:.
when you run timingtim eByFrames it reports no dropped frames and low interframe interval variance when iohub is running and when it is not. So iohub is not affecting inter frame intervals when using that test.
when you r un the your test script and get both.event and.iohub kb event times for each trial response, they are the same (within 0.5 msec). when you run 2) without iohub you get BBTK RT vs psychopy RT differences.