Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Keyboard latency

danluu.com

Post reply on HN
Print view View original

191–200 of 274 posts

Re: Keyboard latency

#191

Post by rcthompson »

pdkl95 wrote: post #92
colanderman wrote: post #9

I'm surprised the "humans don't notice 100 ms" argument is even made. That's trivially debunkable with a simple blind A/B test at the command line using `sleep 0.1` with and without `sleep` aliased to `true`. To my eyes, the delay is obvious at 100 ms, noticeable at 50 ms, barely perceptible at 20 ms, and unnoticeable at 10 ms. Not to mention that 100 ms is musically a 16th note at 150 bpm. Being off by a 16th note e…

> strike a key less than 100 ms after some visual stimuli, I'm sure I couldn't do it The video game "Super Hexagon"[1] is a surprisingly interesting demonstration of this limitation, and how the mind tries to workaround the problem. The higher difficulties ("hexagonest"[2]) seem impossible at first. In the easier levels you can react , but now the time it takes to see the scree, parse the simple graphics, recognize t…

I don't think it's a matter of achieving a faster reaction time by bypassing higher brain functions. It's about looking several steps ahead and planning out multiple steps before you need to do them, and then anticipating when each action needs to happen.

One game that really demonstrated this to me was Crypt of the Necrodancer. It's a rougelike where each turn is the beat of a song, and the tempo of the song for each floor is slightly faster than the previous floor, starting at 120 bpm (1/2 second per turn) on floor 1 and topping out around 180 bpm (1/3 second per turn). For the slow songs, you have enough time between beats to fully plan your next action, but at some point, as the tempo gradually increases from floor to floor, you hit a point that this is no longer possible, and your brain has to "switch modes" to planning several beats ahead and thinking in patterns instead of individual moves.

Re: Keyboard latency

#192

Post by Kadin »

pdkl95 wrote: post #145
BoppreH wrote: post #117

Earlier quoted context omitted.

This is also clear on rhythm games like Stepmania. Here's a random video from a keyboard user: https://youtu.be/TWiMnENdcyY?t=56 At this speed the player is reacting (and hitting with correct timing) about ten notes (arrows) per second. This is possible by memorizing and reacting to group patterns instead of individual notes, but more importantly, reacting unconsciously. A player can play at this level without consci…

A big difference between Hexagon and most other rhythm games like Stepmania, Beatmanias IIDX, Guitar Hero, etc , is that pattern is the same. Just like musicians memorize complex music that they later perform[1] with precise timing, the same is possible for these step/note patterns. I've personally seen someone perform one of the insane speed/note-density DDR songs blindfolded . Humans have surprisingly good internal…

Super Hexagon is akin to "sight reading" or performing music "a prima vista", while DDR as played by most players is a type of rehearsed musical performance (or, well, dance, I suppose).

Being able to play a prima vista is a rather specialized skill even among musicians; I've only known a handful of people who can do it really well. I don't think it has a ton of utility (at least I never found it to have a lot) and so it's not something that many people actively develop or train, though.

Re: Keyboard latency

#193

Post by semi-extrinsic »

pdkl95 wrote: post #92
colanderman wrote: post #9

I'm surprised the "humans don't notice 100 ms" argument is even made. That's trivially debunkable with a simple blind A/B test at the command line using `sleep 0.1` with and without `sleep` aliased to `true`. To my eyes, the delay is obvious at 100 ms, noticeable at 50 ms, barely perceptible at 20 ms, and unnoticeable at 10 ms. Not to mention that 100 ms is musically a 16th note at 150 bpm. Being off by a 16th note e…

> strike a key less than 100 ms after some visual stimuli, I'm sure I couldn't do it The video game "Super Hexagon"[1] is a surprisingly interesting demonstration of this limitation, and how the mind tries to workaround the problem. The higher difficulties ("hexagonest"[2]) seem impossible at first. In the easier levels you can react , but now the time it takes to see the scree, parse the simple graphics, recognize t…

On a similar note, a fast baseball takes less than 450 ms to go from the pitcher's hand to the plate. The "turnaround time" for the bat, from when it starts moving until it hits the ball, is 150 ms. That leaves about 300 ms in which the batter must first spend some time analyzing the path and spin of the ball, then decide whether and how to hit the ball. The only way to make it work is subconsciously.

Re: Keyboard latency

#194

Post by abakker »

rcthompson wrote: post #191
pdkl95 wrote: post #92

Earlier quoted context omitted.

> strike a key less than 100 ms after some visual stimuli, I'm sure I couldn't do it The video game "Super Hexagon"[1] is a surprisingly interesting demonstration of this limitation, and how the mind tries to workaround the problem. The higher difficulties ("hexagonest"[2]) seem impossible at first. In the easier levels you can react , but now the time it takes to see the scree, parse the simple graphics, recognize t…

I don't think it's a matter of achieving a faster reaction time by bypassing higher brain functions. It's about looking several steps ahead and planning out multiple steps before you need to do them, and then anticipating when each action needs to happen. One game that really demonstrated this to me was Crypt of the Necrodancer. It's a rougelike where each turn is the beat of a song, and the tempo of the song for eac…

This sounds kind of like how stenographers’ keyboards work. You plan and type words with key combos. Much faster than typing since you react to whole words and think in phrases (so I was told).

Re: Keyboard latency

#195

Post by nojvek »

Skunkleton wrote: post #182

On linux, after keyboard has decided that a key has been pressed, and is ready to tell USB about it. 1. Wait for USB to poll. 2. Handle interrupt urb generated by keyboard. 3. Propagate the urb to the correct driver for completion 4. Create input events for each key event in this urb. Don't forget to use this to add to your randomness pool! 5. Pass the key event to user space, and wake up readers. 6. Some library rea…

Computers are fast. 100ms is eons for things that just run on CPU. With a 2ghz computer, you can count from 1 to almost a billion. That's a billion little steps that can happen in the blank of an eye.

Re: Keyboard latency

#196

Post by mrkgnao »

gregmac wrote: post #34
colanderman wrote: post #9

I'm surprised the "humans don't notice 100 ms" argument is even made. That's trivially debunkable with a simple blind A/B test at the command line using `sleep 0.1` with and without `sleep` aliased to `true`. To my eyes, the delay is obvious at 100 ms, noticeable at 50 ms, barely perceptible at 20 ms, and unnoticeable at 10 ms. Not to mention that 100 ms is musically a 16th note at 150 bpm. Being off by a 16th note e…

Hm, neat. I notice about the same result -- 0.1 is quite obvious. If you want to blind A/B test yourself, run this: DELAY='0.1'; VALUES=(0 0); VALUES[$((RANDOM % 2))]=$DELAY; alias test_a="sleep ${VALUES[0]}"; alias test_b="sleep ${VALUES[1]}" Adjust DELAY as you want, and then use test_a and test_b and see if you can guess which is which, then run alias to see for sure.

I can get it down to 1ms, so there's probably something wrong with my setup. (I just look for how the cursor moves; on the delayed one, I can discern the presence of the cursor on the next line for a split second.) Maybe monitor refresh rate, or the minimal resolution sleep can handle?

I'm using Alacritty, which is supposed to be really fast and everything!

Re: Keyboard latency

#197

Post by Kadin »

lightedman wrote: post #175
colanderman wrote: post #9

I'm surprised the "humans don't notice 100 ms" argument is even made. That's trivially debunkable with a simple blind A/B test at the command line using `sleep 0.1` with and without `sleep` aliased to `true`. To my eyes, the delay is obvious at 100 ms, noticeable at 50 ms, barely perceptible at 20 ms, and unnoticeable at 10 ms. Not to mention that 100 ms is musically a 16th note at 150 bpm. Being off by a 16th note e…

"To my eyes, the delay is obvious at 100 ms, noticeable at 50 ms, barely perceptible at 20 ms, and unnoticeable at 10 ms." That's how it goes with my ears when recording as well. Most "Live feedback" mechanisms for guitar programs (heck even computer-made guitar hardware) have about 50ms of latency, which is quite disconcerting when you're doing something heavily timing-based. 10ms is almost imperceptible to me (soun…

This is why I'll never buy a DAC that doesn't have a headphone monitor output on the front panel! The performance of low-latency audio has gotten worse over time, not better, at least on the Mac. (It was better under OS 9 than anytime since, I think.)

Another fun test you can do, if you have an analog mixer, is to run some input signal into the mixer, then to the PC, and then from the PC back out, and monitor both the original input and the signal from the PC at the same time. OS-supplied drivers typically make it sound like you're in the Grand Canyon.

But even with very expensive low-latency gear, you can still tell if you put one signal into the left headphone channel and another into the right. If there's actually zero latency, you'll perceive the sounds as coming from directly in front of (some people perceive as directly behind) you. It'll sound just like mono. Any latency, given the same volume level, will be perceptible as a difference in "location" of the sound.

My unscientific experiments suggest that you can perceive down to about 1ms latency quite clearly this way across most of the audible range. The minimum is frequency dependent (as you'd expect) with lower frequencies being less sensitive.

Presumably the human brain has evolved to be extremely good at arrival time comparisons (maybe even doing some sort of phase-difference stuff) as a way of triangulating the origin point of sounds. There are doubtless other specialized ways in which the brain is equally sensitive, so the 100ms rule of thumb seems pretty naive to me. 100ms might hold true for the "main loop" of the human brain at the level of conscious thought, perhaps.

Re: Keyboard latency

#198

Post by snvzz »

colanderman wrote: post #9

I'm surprised the "humans don't notice 100 ms" argument is even made. That's trivially debunkable with a simple blind A/B test at the command line using `sleep 0.1` with and without `sleep` aliased to `true`. To my eyes, the delay is obvious at 100 ms, noticeable at 50 ms, barely perceptible at 20 ms, and unnoticeable at 10 ms. Not to mention that 100 ms is musically a 16th note at 150 bpm. Being off by a 16th note e…

>On the other hand, if you told me to strike a key less than 100 ms after some visual stimuli

If it was audio cue, I'd point you to "Love Live School Idol Festival", a rhythm game which "perfect" judgement window is some 32ms. Decent players will get perfect most of the time.

Re: Keyboard latency

#199

Post by snvzz »

mrkgnao wrote: post #196
gregmac wrote: post #34

Earlier quoted context omitted.

Hm, neat. I notice about the same result -- 0.1 is quite obvious. If you want to blind A/B test yourself, run this: DELAY='0.1'; VALUES=(0 0); VALUES[$((RANDOM % 2))]=$DELAY; alias test_a="sleep ${VALUES[0]}"; alias test_b="sleep ${VALUES[1]}" Adjust DELAY as you want, and then use test_a and test_b and see if you can guess which is which, then run alias to see for sure.

I can get it down to 1ms, so there's probably something wrong with my setup. (I just look for how the cursor moves; on the delayed one, I can discern the presence of the cursor on the next line for a split second.) Maybe monitor refresh rate, or the minimal resolution sleep can handle? I'm using Alacritty, which is supposed to be really fast and everything!

Likely forking sleep takes time.

Re: Keyboard latency

#200

Post by Pxtl »

pdkl95 wrote: post #92
colanderman wrote: post #9

I'm surprised the "humans don't notice 100 ms" argument is even made. That's trivially debunkable with a simple blind A/B test at the command line using `sleep 0.1` with and without `sleep` aliased to `true`. To my eyes, the delay is obvious at 100 ms, noticeable at 50 ms, barely perceptible at 20 ms, and unnoticeable at 10 ms. Not to mention that 100 ms is musically a 16th note at 150 bpm. Being off by a 16th note e…

> strike a key less than 100 ms after some visual stimuli, I'm sure I couldn't do it The video game "Super Hexagon"[1] is a surprisingly interesting demonstration of this limitation, and how the mind tries to workaround the problem. The higher difficulties ("hexagonest"[2]) seem impossible at first. In the easier levels you can react , but now the time it takes to see the scree, parse the simple graphics, recognize t…

To be fair, Super Hexagon relies heavily on repeated scripts of barriers, and only throws truly random geometry at you for the briefest moments where it's switching from one script to the next. I honestly found that the most frustrating part of the game - I'd see a new script and die.... But there's no way to force replaying that script. The game is random, so you have no way to learn to dominate one challenging bit, you just hope you'll figure it out next time it comes up, or hope it doesn't come up. I beat the "Harder" mode without ever figuring out how to beat some of the rarer scripts.
Post reply on HN