Does 49.92Hz vs. 50Hz cause stutters? (Cycle-exact mode)

[Photon]

1. For hardware, PAL spec is === 50Hz, while various systems strived to get close (just as when you set up a pixelclock for PC) and displays picked up the slack (adapted to detect and display the signal, rounding it back to even Hz).

2. Amiga PAL output is 49.9204... Hz. This is lower FPS meaning the Amiga has a few extra cycles available for generating visuals than if it output 50 Hz.

3. Under WinUAE options > Display, PAL is referred to as 50 Hz, not 49.92.

4. If Cycle-exact is cycle-exact then, this should cause stutters for really tight demos, or tight games such as Turrican II etc.

The fix is obviously to not go Cycle-exact for recording etc - I just wanted to check if 1-4 is correct. I.e. that there's no fix or patch in WinUAE for the slight discrepancy to make it smoother on 50/100Hz capable displays or something like that.

[Toni Wilen]

From Amiga program point of view nothing changes, emulated hardware still has exact same cycles and exact same timing even when FPS. Adj gets changed. To any value, even if it is 10Hz or 100Hz.

Same with "warp mode". Emulated timing won't change (expect if in fastest possible mode but thats by design anyway)

It still can cause stutters, especially if traditional vsync (which is exactly the reason why default is 50Hz) but with G-Sync/FreeSync it does not matter, anything inside variable refresh rate support works perfectly smoothly, including 50/60Hz on the fly changes.

Basically Display panel settings do not affect emulator accuracy. It only affects what you see (or even hear), not what emulated program sees

(Note that Turrican II can stutter very badly when "too many" enemies are visible at the same time. It is not emulation problem.)

[Photon]

Thanks, I guess it's easy enough for the emulation to decide when the "Amiga frame" is over.

It obviously emulates a 7MHz CPU fast enough to do this at hundreds to thousands of FPS, if VSync is off. So it has plenty of time to wait for the PC to VSync, and at 50 times per second, the frame buffer is changed, across whatever HZ the monitor is set to, giving e.g. 50 FPS @ 60 Hz or 50 FPS @ 100 Hz.

One of those 50 frames per second, every 12.5 seconds, will be a duplicate frame, a small stutter.

Is that correct, or does the emulation output a steady 50 FPS (not 49.92) and fixes audio playing across frames etc?

Edit: The emulator seems to output a steady 50 FPS, and I don't see a stutter in 12.5 seconds with VSync on in WinUAE and GPU drivers, at 100 Hz (Monitor without G-Sync/Freesync). So this is what I want for capturing, and stutters PC end would be from slower PCs and (since every Amiga-frame-cycle is emulated) Amiga software that actually overrun the Amiga-frame.

[rsn8887]

I wonder if real A500 and emulated A500 would ever get out of sync with each other, or if they would stay in lock-step for a long time. How long? Someone should test this

If emulation is accurate, even after one hour, the two machines should be on the same frame. The question is how close emulation is to real hardware in terms of wall-time, not cycles.

[Photon]

Originally Posted by rsn8887

I wonder if real A500 and emulated A500 would ever get out of sync with each other, or if they would stay in lock-step for a long time. How long? Someone should test this

If emulation is accurate, even after one hour, the two machines should be on the same frame. The question is how close emulation is to real hardware in terms of wall-time, not cycles.

If the PC emulation doesn't stutter (with VSync on and PC monitor modeline not made for a multiple of 49.92Hz) they will (by the 1 frame per 12.5 seconds I mention). It's a small difference though - PC will be 0.1% faster.

[Toni Wilen]

Originally Posted by rsn8887

I wonder if real A500 and emulated A500 would ever get out of sync with each other, or if they would stay in lock-step for a long time. How long? Someone should test this

If emulation is accurate, even after one hour, the two machines should be on the same frame. The question is how close emulation is to real hardware in terms of wall-time, not cycles.

This has nothing to do with emulation accuracy.

It is by design not in hard (but close enough) sync with real world time because it is the only way to make it usable in most normal PC configurations.

[Photon]

How is audio handled? (Let's say the simplest case, a sample is played by audio DMA, and will play across frames.) It seems to me that if there's no stutter in the framerate, there must be one in sound. If handled once per frame, sometimes 1 sometimes 0 samples for 1 channel skipped. If not handled, well most sounds are shorter than 12.5s so it might not have come up. But a whole 0.02s skipped then, quite audible.

[rsn8887]

I think the audio speed (pitch) is ever so slightly adjusted in WinUAE to keep audio in sync with video, and keep it all smooth, but maybe that has changed at some point.

[rutra80]

To me it seems that currently when hard sync is forced to non-native framerate then audio stutters.

[Toni Wilen]

If not vsync: emulation is synced to audio, in other words, emulator waits if previous audio buffer is not yet available. This causes emulator to usually run very slightly slower than real hardware (in real world time, emulated program does not see anything wrong)

if vsync: synced to video, audio is expected to run in sync but in reality it isn't fully in sync and can cause periodic glitches. This needs improvements. (two sync sources: very difficult task)

Currently most stable setup is variable refresh monitor (gsync/freesync) because it works like vsync but it is monitor that follows emulator's frame timing (there is only one sound source: sound) which is opposite to normal vsync where emulator needs to follow the display frame timing.

I have already repeated this many times but here it is again: if you use emulators, get gsync(compatible)/freesync monitor! (But check the specs first, some very basic freesync monitors only have frequency range of something like 60 to 75 or so which is useless for PAL emulation)

[Photon]

Special monitor only fixes it for your pair of eyes, and VSync off already works.

Is there some solution to allow screen capture, streaming, etc (with VSync on to avoid tearing, off already works)? I.e. perfect picture and sound. How is it handled for recording (Output)? (if video FPS is set to 50).

[dreadnought]

Originally Posted by Toni Wilen

I have already repeated this many times but here it is again: if you use emulators, get gsync(compatible)/freesync monitor! (But check the specs first, some very basic freesync monitors only have frequency range of something like 60 to 75 or so which is useless for PAL emulation)

Why is that not enough? I thought that as long as the monitor is doing the syncing up to 60Hz, it should be ok...(as per that other recent thread).

[DamienD]

Originally Posted by dreadnought

Why is that not enough? I thought that as long as the monitor is doing the syncing up to 60Hz, it should be ok...(as per that other recent thread).

I'd imagine that as PAL is 50Hz then you need a gsync (compatible) / freesync monitor that supports multiples of 50...

Obviously "60Hz" and "75Hz" only are not going to cut it.

[dreadnought]

Possibly, but why multiples? The syncing for modern games is different (possible under 60Hz), so I suppose it's something to do with emulation.

[Photon]

For now, most of the questions have been answered by Toni so that only a perfect preservation video format is left.

Monitors can only add fixes to get closer to CRT without VSync, nothing else. FPS must be close to and under Hz, framerate doesn't vary as in 3D games. Multiples of 50 or visuals are back to VSync off.

[rutra80]

Amiga doesn't produce perfect 50/60 Hz so with most monitors there will be audio glitches with vsync.

[Photon]

Originally Posted by rutra80

Amiga doesn't produce perfect 50/60 Hz so with most monitors there will be audio glitches with vsync.

Hehe. This topic is about more detail than that.

There's also more detail to an answer like that. For example, there will be no glitches with CRT monitors (PC or otherwise). Just horrendous flickering from poor quality phosphor layer in PC CRT monitors. And when it comes to screens whose best quality according to lamers is that they're flat (but the stand is still as deep as a CRT and now occupies the spot where you normally place a keyboard), obedience to V/Hfreq is up to the quality of the chip inside (many flat monitors and TVs support it), and ability of OS to create modelines to reach them.

There are websites for this, but because it's technical it will be out of reach of the many.

Certainly the Amiga can output an exact 50Hz framerate. The goal is to reach perfect video (achieved) AND audio (awaiting solution).

[rutra80]

Yes I only meant in what current WinUAE implementation results - if someone uses vsync on non-variable-refresh monitor then there will be audio glitches because Amiga standard modes aren't exactly what PC monitor outputs.