RetroArch 1.9.13 released, adds automatic frame delay
It's time to go grab a new version of RetroArch. The Libretro team has just put out the latest version--1.9.13--which as usual, adds a few new fun features to the emulation frontend. Spotlighted in this update is the new automatic frame delay feature; yet another capability that helps lessen latency with emulators. This automates a previously existing option, making it easier for the end user, and works with all cores on RetroArch. A more detailed breakdown of what exactly frame delay is, and what this feature does was written up by the devs and can be seen below.
What is “Frame Delay”?
The setting known as “Frame Delay” has actually existed for some time in RetroArch. However, due to its nature and the complexity of its effect, it has always required a level of strictly manual adjustment and finetuning on the user side.
To best describe the underlying mechanism, let us briefly touch upon the timing of when a new frame is produced (including when the inputs are sampled) and then displayed on-screen.
The way frames are rendered and then displayed on video can be best understood by considering this sequence:
• each frame has a set duration, namely a “frame time” or “frame period” as it is usually called, which on a 60hz screen and in ideal circumstances corresponds to a length of 16.7 milliseconds on average;
• as per the picture shown above, once the first frame is shown the next frame starts being prepared “behind the scenes”. This rendering process includes the moment the inputs are polled and it all happens within the allotted frame period;
• in typical situations the rendering process of the next frame is finished some time before the given frame period is over;
• this results in the next frame essentially “stalling”, being left in a suspended state for a few more milliseconds than necessary, until the frame period is properly finished;
• only at that point the newly created frame is presented on-screen.
While the process described here is normal and does not usually yield a considerable impact on latency, the fact that the next frame has to be put “on hold” and wait a certain amount of time from the moment it finishes rendering until the end of the frame period does in fact contribute to the combined responsiveness of the inputs.
This is where “Frame Delay” comes into play.
Depending on the value set for the “Frame Delay” option, the creation of the new frame including the input polling can be postponed by a certain number of milliseconds, until the last moment that is realistically viable.
Doing this requires some additional CPU processing power depending on the chosen amount of delay, but it also helps decrease the number of milliseconds that the new frame – which has been prepared and is ready to be presented on video – has to remain on hold. As a consequence, adjusting the “Frame Delay” setting can offer a slight – albeit measurable – improvement to the perceived input latency.
Beyond that, mGBA has seen an update that gives it better audio--no more crackling, while gpSP has added a dynamic recompiler for 64bit CPUs. This version update is not available on the Google Play Store, and likely won't be for the time being, due to issues with the Play Store's new policies regarding apps. If you want to grab v1.9.13, you can do so at the source link.
Source
Or others 
