Hacker News Reader

Input in NES is not lag's source. Input is only read once per frame. Today it is very simple and cheap to improve over old controllers.

Lag comes from video. If you do not use FPGA emulators like Mister the video delay is enormous.

I don't understand what you are calling 10ms lag. Have you measured the delay between your computer and your screen? It is way bigger than that, in any computer or NES console(console-TV).

Are you maybe referring to 10ms NETWORK packet delay? All TVs or projectors use buffers, and it takes time for information to travel around serial cables.

Network delay is inconsistent, but electronic delay is not.

> Input in NES is not lag's source. Input is only read once per frame.

That’s exactly what I said ;) By virtue of being a different platform, emulation introduces a lag that is just not present on the real hardware (and can’t be lower by virtue of literally being a wire to memory). USB alone often introduces an astoundingly high minimal floor on latency.

> I don't understand what you are calling 10ms lag. Have you measured the delay between your computer and your screen? It is way bigger than that, in any computer or NES console(console-TV).

Yes I have measured it (on all my devices, accurately so) in order to minimise it as much as possible (I can work with but can’t stand latency, even in a terminal).

Rock Band, which I used to be an avid player of, allows you to adjust a relative delay (audio and video separately), timewarping A/V so that all three are perfectly in sync relative to real-world input.

> Network delay is inconsistent, but electronic delay is not.

I agree (and agree to buffers as well), but by and large any modern device is far removed from being just electronic, from USB (USB 2.0 has a 125us polling loop for multiplexing, USB 3 is point to point so can fare much better at 30us, but even then there’s kernel context switch to read and process that data) to HDMI (packet based with loads of multiplexing), many things end up being surprisingly subject to soft-real-time firmware/software before it hits the display itself. Hard real time stuff probably exists because the specs now allow for it but good luck finding that in consumer space where it’s much easier (read: cheaper) to push a best effort implementation.

But my point isn’t about the minutiae of lag source, it’s that the human brain is severely impacted by lag, can adjust to some extent but the cost is paid heavily at multiple levels and with various efficacy crippling consequences; and that Q3 and subsequent games have increasing numbers of facilities to create the illusion that everything happens in sync so that we’re not so impacted by it.

> the human brain is severely impacted by lag

The brain can compensate for lag/latency up to a point. Church organ players often have to deal with >100ms of delay between pressing a key and hearing the note produced through those big pipes.

If you have an app which produces a sound when you tap on the screen, and there's a delay of say 70ms between tapping and sound being produced, it's easily possible to play in time with an external clock source, like a metronome, as long as the delay is fixed.

In the 1968 paper "Response time in man-computer conversational transactions" actions which occurred within 100ms the human input were perceived as instantaneous. In my experience this holds true with musical instrument apps, although one must first learn how much latency is present in order to compensate for it when synchronising with other clock sources.

Can confirm that many musicians have to play with latency. Pipe organs, heavily processed guitars (delay is an effect that is very commonly used) all are laggy and you have to play ahead of your accompaniment.

True for organists (for which I don’t know much about, but read on, as I believe the following applies to them as well)

The fact that the effects are laggy doesn’t mean you need to sync on them, you’re mostly listening whether the sound envelope is correct (e.g adjust for overshoot/undershoot a bend). Checking the output of effects only matters at timescales of whole beats/measures in terms of how you have to react, definitely not like keeping up with tempo, which has to be precise across the band.

You don’t get delay on drums, and exceedingly rarely so on bass, which is what you have to react agains efficiently, plus the instrument you’re playing provides its own subtle and not-so-subtle haptic feedback. On a guitar, this means the moment you pluck the chord is based on your internal clock synced by listening to the tempo giver (usually bass).

Source: amateur musician myself, wife is pro.

Do you find it impossible to talk to a person 10 feet away? Because their audio has a roughly 10ms latency.

No, because I don’t have to react on their output on a millisecond timescale.

> Try playing on Zoom, it’s absolutely impossible (unless you assume latency is fixed, which it is not, and play in a tempo matching latency exactly, and follow the lead but time-warp your play by one beat, which I imagine is possible as a sort of canon but absolutely horrendous) unless you completely ignore the other part and find a common time source to sync upon.

Zoom's latency isn't fixed, so that won't work. On the other hand, it is possible to do something like this over the internet by measuring latency and then adjusting for it: www.jefftk.com/p/bucket-brigade-singing

> Anything below 60Hz in VR has a significantly increased chance of giving motion sickness due to latency.

I think there is a subtle difference between fps (avg) and latency. I would say that a 'stable' latency is always better than a high fps.

> Try Guitar Hero / Rock Band with various audio / video latency settings. 10ms is obviously impactful, anything higher borderlines on unplayable, and even 5ms has a subtle impact increasing missing notes.

Do you mean that you set an additional latency for both video and audio? Or you delay only the audio by 10ms?

> I think there is a subtle difference between fps (avg) and latency

Yup, I only mentioned 60Hz, because 16.667 ms is more obvious WRT latency but less known.

> Do you mean that you set an additional latency for both video and audio? Or you delay only the audio by 10ms?

No, RB allows you to set up the audio and video latencies, and since the track is fully known, it’s able to apply negative latency to everything but the input (which, being physical user input, is the only thing that can’t be altered).

So you set up input->audio latency and input->video latency values and the game will internally play them ahead, so that they appear exactly in sync in the physical world.