| Both sides previous revision Previous revision Next revision | Previous revision |
| latency_reduction_and_performance [2022/07/05 02:18] – ↷ Page moved and renamed from playground:latency_reduction to latency_reduction_and_performance atari | latency_reduction_and_performance [2025/09/11 00:49] (current) – [USB polling rate] specify that it's not global atari |
|---|
| ====== Latency Reduction and Optimising Performance ====== | ====== Latency Reduction and Optimizing Performance ====== |
| |
| Many things can be set in Batocera to reduce input delay and increase performance of its emulators. First, let's go through the latency reduction settings typical to RetroArch cores (a core must explicitly support these options, you can tell by whether or not they appear in the system's **ADVANCED SYSTEM OPTIONS**): | Many things can be set in Batocera to reduce input delay and increase performance of its emulators. First, let's go through the latency reduction settings typical to RetroArch cores (a core must explicitly support these options, you can tell by whether or not they appear in the system's **ADVANCED SYSTEM OPTIONS**): |
| |
| ===== Run ahead ===== | ===== Run-ahead ===== |
| |
| This solution approaches the situation from the game-side. When you press a button, RetroArch rewinds # frames in the past (where # is the amount of frames set in **RUN AHEAD FRAMES**) and calculates what would have happened if you had pressed the button for # frames up to the current point in time. Then it brings that frame to the moment you pressed the button. It can be thought of as doing a mini-rewind-fast-forward every time a button is pressed; most machines are powerful enough to perform this nearly instantaneously. | This solution approaches the situation from the game-side. When you press a button, RetroArch rewinds # frames in the past (where # is the amount of frames set in **RUN AHEAD FRAMES**) and calculates what would have happened if you had pressed the button for # frames up to the current point in time. Then it brings that frame to the moment you pressed the button. It can be thought of as doing a mini-rewind-fast-forward every time a button is pressed; most machines are powerful enough to perform this nearly instantaneously. |
| |
| By default, RetroArch will use the current game state being emulated to do all its calculations. This can result in choppy audio as the emulated game is rapidly fast-forwarded. By turning on the **USE SECOND INSTANCE** option, RetroArch will instead run a second version of the game in the background, and simply switch to it when the calculations are complete resulting in less audio crackle. Obviously, this doubles the CPU requirements to use, but most machines have plenty enough overhead to handle it. | By default, RetroArch will use the current game state being emulated to do all its calculations. This can result in choppy audio as the emulated game is rapidly fast-forwarded. By turning on the **USE SECOND INSTANCE** option, RetroArch will instead run a second version of the game in the background, and simply switch to it when the calculations are complete resulting in less audio crackle. Obviously, this doubles the CPU requirements to use, but most machines have plenty enough overhead to handle it. |
| |
| ===== G-sync/Freesync/VRR ===== | |
| |
| One disadvantage that digital displays have when compared to traditional [[:batocera-and-crt|CRTs]] is that they run their own little computer micro-managing the display. What this amounts to is that the display's refresh rate (how often it "draws" a frame) is independent of the machine sending the frames; the computer running the emulator. The emulator has the frame ready, but must wait for the display to be ready to "draw" a new frame before the image can actually appear, causing a bit of a delay. In addition, digital displays typically only display in certain multiples (50, 60, 100, 120 Hz etc.) whereas game systems (especially handhelds and arcade) could have been running at any refresh rate, causing even more delay/frame judder.((RetroArch's timing skew feature forces games that run "close enough" to the display rate of your monitor to run the few percent faster/slower to make the game match the refresh rate, creating a smoother experience but at the obvious downside of the game being run at a different speed than native hardware. It's such a small amount that it's usually not even noticeable, but if it weren't present then users who can't activate Variable Refresh Rate would notice issues like audio crackling. A notable example being Robocop (ran at 57 Hz, a very unusual refresh rate not supported by pretty much any digital display).)) | |
| |
| But through the wonders of modern technology, on certain displays this disadvantage exists no longer! | |
| |
| G-sync/Freesync/Variable Refresh Rate all refer to the same concept; instead of sending frames to your display sixty times a second and having it wait until the next refresh, instead have the refresh rate dictated by the software. This eliminates the problems mentioned above with digital displays, but the downside is that the display itself must explicitly have support for the technology. Certain gaming PC monitors will have this, and a few TV displays as well. It should be enabled where supported, as there's no downside. | |
| |
| ===== Auto-frame delay ===== | ===== Auto-frame delay ===== |
| You might be wondering, how does this all apply if you are using Variable Refresh Rate? The technicalities are very complex, but essentially instead of syncing to whatever the display's refresh rate is for the delay, you're merely syncing to how much delay the machine itself is giving each frame. | You might be wondering, how does this all apply if you are using Variable Refresh Rate? The technicalities are very complex, but essentially instead of syncing to whatever the display's refresh rate is for the delay, you're merely syncing to how much delay the machine itself is giving each frame. |
| </WRAP> | </WRAP> |
| | |
| | ===== G-sync/Freesync/VRR ===== |
| | |
| | One disadvantage that digital displays have when compared to traditional [[:batocera-and-crt|CRTs]] is that they run their own little computer micro-managing the display. What this amounts to is that the display's refresh rate (how often it "draws" a frame) is independent of the machine sending the frames; the computer running the emulator. The emulator has the frame ready, but must wait for the display to be ready to "draw" a new frame before the image can actually appear, causing a bit of a delay (at least when V-sync is enabled, which is the default for Batocera). In addition, digital displays typically only display in certain multiples (50, 60, 100, 120 Hz etc.) whereas game systems (especially handhelds and arcade) could have been running at any refresh rate, causing even more delay/frame judder.((RetroArch's timing skew feature forces games that run "close enough" to the display rate of your monitor to run the few percent faster/slower to make the game match the refresh rate, creating a smoother experience but at the obvious downside of the game being run at a different speed than native hardware. It's such a small amount that it's usually not even noticeable, but if it weren't present then users who can't activate Variable Refresh Rate would notice issues like audio crackling. A notable example being Robocop (ran at 57 Hz, a very unusual refresh rate not supported by pretty much any digital display).)) |
| | |
| | But through the wonders of modern technology, on certain displays this disadvantage exists no longer! |
| | |
| | G-sync/Freesync/Variable Refresh Rate all refer to the same concept; instead of sending frames to your display sixty times a second and having it wait until the next refresh, instead have the refresh rate dictated by the software. This eliminates the problems mentioned above with digital displays, but the downside is that the display itself must explicitly have support for the technology. Certain gaming PC monitors will have this, and a few TV displays as well. |
| | |
| | <WRAP center round info> |
| | There is usually no downside to leaving VRR on at all times. If your display's maximum refresh rate matches the exact (or in the unlikely scenario //higher//) frame rate of the content that's being displayed, then VRR would have no effect as it gets disabled by the hardware. However, if this happens when running content with a variable frame rate (such as a PC game or an emulator that's just hard to run), this can cause (minimal) visible tearing when switching between the modes. |
| | |
| | When using RetroArch, this will usually never happen outside of the "can't run the emulator fast enough" scenario. |
| | </WRAP> |
| | |
| | For a video that goes more in-depth on the input delay aspect of VVR and its various technologies, check out this video by Battle(non)sense: [[https://www.youtube.com/watch?v=mVNRNOcLUuA|FreeSync vs. G-Sync Delay Analysis]]. It does focus on the PC gaming aspect of it though, where variable frame rates are abundant, not necessarily the case with emulation. |
| |
| ===== Threaded video ===== | ===== Threaded video ===== |
| ==== USB polling rate ==== | ==== USB polling rate ==== |
| |
| It is possible to globally alter the USB polling rate, in addition to the driver's polling rate internally. USB polling rate is controlled by the ''usbhid.jspoll'' option, while the xpad driver's polling rate is controlled by ''xpad.cpoll''. These are added to the boot line. For example: | It is possible to alter the USB polling rate, in addition to the driver's polling rate internally. USB polling rate is controlled by the ''usbhid.jspoll'' option, while the xpad driver's polling rate is controlled by ''xpad.cpoll''. These are added to [[:troubleshooting#x86_x86_64|the boot line]]. For example: |
| |
| <code> | <code> |
| ''usbhid.jspoll=0 xpad.cpoll=0'' are the default settings, whatever the kernel itself requests. | ''usbhid.jspoll=0 xpad.cpoll=0'' are the default settings, whatever the kernel itself requests. |
| |
| ''usbhid.jspoll=1 xpad.cpoll=1'' changes the polling rate for USB devices and the xpad driver to be 1000mHz instead. | ''usbhid.jspoll=1 xpad.cpoll=1'' changes the polling rate for generic USB devices (like keyboards and mice) and the xpad driver for some generic pads to be 1000mHz instead. |
| |
| ==== USB auto-suspend ==== | ==== USB auto-suspend ==== |
| Certain USB devices will "auto-suspend" when they become inactive (ie. stop using power) and re-activate when interacted with. When this is functioning as intended, it is no different from operation without auto-suspend. However, if I had a coin for every time an electronic device functioned the way it was intended to... | Certain USB devices will "auto-suspend" when they become inactive (ie. stop using power) and re-activate when interacted with. When this is functioning as intended, it is no different from operation without auto-suspend. However, if I had a coin for every time an electronic device functioned the way it was intended to... |
| |
| It is possible to globally disable the auto-suspend option, such that no USB devices go into power saving mode. You would add ''usbcore.autosuspend=-1'' as an option to your boot line. So for example: | It is possible to globally disable the auto-suspend option, such that no USB devices go into power saving mode. You would add ''usbcore.autosuspend=-1'' as an option to your [[:troubleshooting#x86_x86_64|boot line]]. So for example: |
| |
| <code> | <code> |