Maybe skip the frameskip...

You won't get real-time video from Dosbox because Dosbox doesn't record any skips or stutters. It's easy to demonstrate just by setting a very high number of cycles and then recording a video. When playing, Dosbox stutters and skips a lot, but the recorded video won't have any of that.

You can reduce the amount of de-sync by using smaller values of "cycles", but you can't eliminate it. Whenever dosbox doesn't get enough CPU time, it will drift slightly out of sync with "real time". The longer the videos, the more pronounced the effect.

One thing that may help is to make sure DOSBox never reaches 100% CPU usage (on its core).

Thank you guys for the tips. It lets me know I probably am not missing something.

Bloodbat: That's a good suggestion. I tried it a couple of times before the time trials and frameskip 0 usually lagged behind quite a bit as the video got above 15 minutes on my rig (which is a good rig, but not a great rig). I don't have any times of it though, all I'm left is my qualitative "it drifted worse than setting a frameskip."

h-a-l-9000: That's something to watch. I don't think DOSBox has pegged the CPU, but I don't know because I haven't confirmed it. Given I'm getting a video "timewarp" perhaps this is happening more than I think, especially when the AI "thinks" about where it's going to move its troops (Warlords and Master of Magic).

ripa: Thanks. This is the sort of definitive answer that I was looking for, and explains why my longer let's play experiments were more out of sync. The last one I did for Warlords, even at 3000 cycles and 2 frameskip, I just couldn't chop up enough in Audacity to get it to work (well, I probably could have if I spent a LOT of time :) ).

I dig how compressed and clean the video capture is in DOSBox, but I'll make sure to not try to do live commentary with DOSBox video directly while recording it.

Thanks all!

I thought about this problem a bit more and experimented with Dosbox's source. I quickly hacked in a feature where Dosbox keeps track of the drift between real time and emulated time, and whenever the drift grows too large (currently > 10 millisec), Dosbox automatically tries to catch up by using the already existing speed unlocker (= same thing as the turbo button combo alt-f12).

It seems to work when using fixed cycles as long as the average CPU load is less than 100% (of a single CPU core). If the cycles count is set too high, dosbox can't accelerate. Also, it doesn't play nice with the auto cycles adjustment (cycles=max or cycles=auto).

Here's a patch against Dosbox SVN r3798 and Windows executables built with MinGW (the MinGW DLLs are bundled for convenience).

I only tested this with One Must Fall 2097, but according to the drift gauge I put into the title bar, the drift stays within the limit even when video capture is on. Without the "catch-up" feature, the drift gradually keeps increasing, which, I think, leads to problems with synchronizing the video to an external voiceover track.

If you have the time, could you check if this solves your recording synchronization problem? Just set fixed cycles like cycles=30000 instead of cycles=auto or cycles=max.

If this works, it could probably be made to work with cycles=auto and cycles=max settings. Dosbox just needs to reduce the amount of emulated cycles whenever it needs to catch up.

Wow. I'm only able to do 1 test right now. Here's what I've done. Please let me know if I missed something or did something in my procedure that you weren't expecting. No matter if I missed something, though, the results are impressive to me.

Game: Master of Magic, patch 1.31
Cycles: 10,000
Frameskip: 2
Stopwatch Duration: 15:00
Running Audacity at normal process priority and recording my (this time fake) commentary as I played. I did make sure to talk a lot, but I talked a lot about nothing since I was just wasting time to fill the commentary with some data.

Results were impressive. Using ffmpeg to check the time of the video capture, the DOSBox video came in at 15:00.48. My audacity commentary, post editing (which has about 0.5 second error as I listen to aural cues on where to splice) came in at 15:00.29.

Even taking into account my errors, and adding for the fact that I've probably done this process upwards of 20 times now (practice plus my Warlords Let's Play), I think it's safe to say your drift fix is a drastic improvement and that my times are relatively accurate, even if they aren't as precise as an integrated video capture plus audio commentary capture system. I've never yet gotten something that, duration wise, was that close until now.

Please double check how I implemented the fix:
* Take existing copy of DOSBox 0.74.
* Copy it.
* Paste it someplace else.
* Copy in your files from the patch (which most significantly looked to be the recreated .exe, although I did copy everything over).
* Point D-Fend Reloaded DOSBox reference to the new DOSBox (aka. use D-Fend GUI to modify the MoM config file.)

Things to note:
* D-Fend freaked out about the sound, so no sound came out while playing. I'm not sure why, but I tried making the MoM profile twice, and each time D-Fend gave me weird errors. Oh well, I played without sound (but see below).
* Sound _did_ come out in the video (I watched various chunks, but not the entire 15 minutes). Nice and crisp, and ffmpeg showed the existence of the audio as one of the two streams in the capture.
* I did not take the time to actually overlay my commentary to confirm things stayed in sync. That would be another test that I can perform tomorrow or at a later date. But I think having the video capture + audacity recording be so close in length is a great sign.

Very cool work. Thank you for considering looking for a fix for this. Please do let me know if you'd like me to run specific other checks, or if something in how I applied the patch seems wrong.

Your sound probably didn't work because this patch was based on dosbox SVN version, which might have some differences in the config file format compared to 0.74. You can run it outside of D-Fend and then edit the configuration file with a text editor to see if that helps. The status window tells where the config file is.

It's also possible that my build environment is bad. I used MinGW, MSYS, and GnuWin32 pre-built libpng and zlib. Someone who has a better build environment with all the optional libs and headers required by Dosbox could try making a better build (that doesn't require all those extra .dlls).

I played One Must Fall for 20 minutes while recording with both Audacity and Dosbox. The Audacity track recorded mic input which means keyboard tapping sounds as well as the Dosbox sound output from the speakers. I mixed both tracks together and included only the beginning and the end:
http://www.sendspace.com/file/n8vjsa

At near 20 minutes the sound is still pretty much in sync, although there is a small time difference between the dosbox track and the audacity track, which is audible as a slight echo. I didn't have to cut or stretch the either track. I just aligned them once before downmixing.

I watched the video, and to me it sounded like things stayed pretty well in sync. The last button click that I heard seemed to correspond to when you clicked the final button in the video.

I've been messing a bit with audacity and latency. It's possible that some latency in the audio overlay can come from... well a lot of factors. I liked this article a lot about dealing with latency issues in audacity:

http://manual.audacityteam.org/man/Latency_Test