Vsync (short for vertical synchronization) is used for synchronizing the game's video output to your display's refresh rate to prevent screen tearing.
Vsync in emulators has historically been problematic, with latency issues caused by driver buffering and stuttering caused by the game running at a different refresh rate than the emulator. Emulators that synchronize on audio may also experience Vsync stuttering when the audio buffers overrun or underrun due to timing imperfections. Some methods for improving Vsync performance on fixed frame rate emulators are discussed below.
Static Rate Control
This audio synchronization method adjusts the audio input rate of the emulated system at startup to match the output rate of the host system, within a certain limit. This allows Vsync to work smoothly even if the game's video refresh rate is not the same as the current display refresh rate. Sufficiently small adjustments should not result in noticeable audio pitch or speed differences, but larger adjustments will be noticeable, so it's usually limited to only up to 5% change in audio rate (on a 60Hz display, this will allow 57Hz-63Hz games to be Vsynced smoothly). The adjustment is not changed after emulator start-up, so slight deviations in frame timing on your system can still cause Vsync stuttering unless you are able to give an exact measurement of your system's timings, which is very difficult or impossible in many cases. May not work well on emulators that use a variable frame rate (i.e not fixed at 50 or 60 FPS for the emulated display).
This method is known to be implemented in higan and RetroArch.
Dynamic Rate Control
This method readjusts audio input rate on the fly to avoid having the audio buffers overrun or underrun due to timing imperfections, which keeps Vsync running smoothly. The amount of adjustment is determined by the dynamic rate control delta, which is usually set at 0.5% by default which is thought to be inaudible to the human ear. Combined with Static Rate Control at startup, this can allow emulation to be almost perfectly synchronized to your display without requiring extremely exact system timing information.
This method is known to be implemented in nemulator, RetroArch, Mesen, BizHawk and Ares.
Hard GPU Sync
This method is for reducing latency associated with Vsync buffering in the video driver. Vendors typically implement buffering in their video drivers to get better scores on benchmarks and better performance on PC games, but this is detrimental to latency, which is especially bad for emulation of older games that were not made with this latency in mind. Hard GPU Sync forces the driver to the only buffer for a specified number of frames at most using the OpenGL extension ARB_sync, potentially improving latency. Buffering for 0 frames is quite demanding on performance and requires the emulator to run many times faster than is necessary to run full speed at 60fps to avoid frame drops. Buffering for 1 or more frames reduces performance requirements. DRM/KMS on Linux can be utilized in a similar manner but with much better performance due to direct control over video buffers.
This method is only known to be implemented in RetroArch.
G-sync and FreeSync
These methods are replacements for Vsync that are being developed by Nvidia and AMD, respectively. These require a new display that supports them and they allow the display to have a variable frame rate to synchronize to the game instead of the game being synchronized to the display.
MAME can make use of this functionality to run arcade games at their native refresh rate with no stuttering and no audio pitch and speed differences. RetroArch can make use of it as well if static syncing and dynamic rate control are disabled by setting "Sync to Exact Content Framerate" to on (Vsync still must be on within RetroArch for this to work).