This section of the forums is the closest I got finding the right place for this topic. Since lsnes is mainly an SNES emulator and this is supposed to be the section for it, I posted it here and not in the GBx section, even though it's about the libgambatte core.
While experimenting with different GBx emulators, I noticed that the frame timing of lsnes is way different from most other emulators, even those who are using the same core (libgambatte). I found the reason in the way lsnes is handling a frame advance:
In lsnes, a frame is forced to be exactly 35112 audio samples long, by running gambatte::GB.runFor in a loop until it is reached (see http://repo.or.cz/w/lsnes.git/blob/refs/heads/master:/src/emulation/gambatte/core.cpp)
In comparison, the Gambatte (SDL) emulator recognizes the VBlank (indicated by the return value) to determine when a video frame has passed. (see https://github.com/sinamas/gambatte/blob/master/gambatte_sdl/src/gambatte_sdl.cpp)
BizHawk is doing something similar to Gambatte, but it ignores the return value under the assumption that a frame can be at most 35112 audio samples long, so a single call of gambatte::GB.runFor ensures to reach the VBlank. (see http://code.google.com/p/bizhawk/source/browse/trunk/BizHawk.Emulation/Consoles/Nintendo/Gameboy/Gambatte.cs)
While both BizHawk and lsnes provide consistent frame timing this way (in the sense of being predictable and reproducable), lsnes timing is completely unrelated to VBlanks. It is true that a video frame is produced every 35112 audio samples as described by the Gambatte documentation, but the ability of GB programs to turn off the LCD messes the count up, making the number of audio samples inbetween video frames longer or shorter. I'm by no means an expert in knowing the GB architecture, but that is how it works afaik.
This causes lsnes to become out of sync with the actual video frames: An lsnes frame then consists of two halves of video frames, having the VBlank somewhere in the middle of the frame. Since the LCD is turned off especially in the initial loading phase of the GB cart, it is out of sync basically all the time.
So what is wrong about being out of sync this way? It largely depends on the method the game uses to read joypad data. If it does it at VBlank (like most games do afaik), the input frames on lsnes can be off. It may even be possible to miss out on input possibilities because of this, when two inputs happen to be in the same lsnes frame, even though they are in different video frames. On the other hand, you might be able to issue inputs that aren't possible on other emulators (they are always possible on console), if it happens the other way round, having two inputs that are in the same video frame separated by the lsnes frames.
I suspect it to be unintentional, i.e., a bug. Changing this woud desync all GB movies, though, and it's not really broken as it is now, just... unintuitive. I guess the acutal question I'm trying to ask here is: what to do about it?