Stuttering is usually from setting cycles higher than what the host machine can handle. If you are trying to run a more demanding game on older or lower end hardware this is more likely to happen. What game and what CPU?

That's the strange thing, many games: Mechwarrior 2 @ 1024 (demanding) or Dune 2 (not demanding). This is on an Intel i7 @ 3.4GHz. It's also not really stuttering per se (I know the crackling at too high a cycle rate), it's an intermittent hiccup here or there, like the game speed is slightly uneven: a slight pause or speed-up, a slightly longer held or overlapping MIDI note, that sort of thing. Completely disappears at any fixed cycle rate the game and host cpu like.

Do both settings (auto and max) 'settle' on a constant cycle rate once a program is running, or does DOSBox adapt continuously? Or maybe OS background processes interfering? Nothing significant is active in the background though.

yeah, with max, dosbox constantly adapts and try to run at the highest value possible.
Maybe, try running with max 95% (press ctrl-f11 once) and see if increasing the frameskip helps.

If you are up to it, we can debug this together a bit as to why it happens on your system. Send me an email or pm if you are up to that

What a coincidence, I have the same problem (only with max but not with fixed cycles), I hope there is a solution for this.

Sorry for reviving this, but I found out I'm having the exact same issue. I noticed, however, if I run dosbox with max cycles just after a fresh reboot, it runs without any stuttering. This only happens if the OS is running for a while and then you run dosbox. Coincidence or not, when dosbox stutters, so does Interstate '76. Dosbox didn't have stutter issues when I ran it on WinXP. I'm on Win7 32 bits.

1core=dynamic
2cputype=auto
3cycles=fixed 40000
4cycleup=5000
5cycledown=5000

Try these settings.

In my experience when dosbox exceeds the cycles your actual CPU is capable emulating, the emulation starts to stutter.
I use 40,000 fixed cycles as a start which equates to a slow Pentium which is fine for most games, sometimes I raise the cycles to 200,000 for a Pentium II range, if needed.
I always use FIXED cycles which is much more reliable way to get accurate CPU clocks with games than Auto with % values.

Using % of you actual CPU is a random hit or miss, I suggest sicking to FIXED cycles and using the Cycle UP/DOWN with a large value like 5000 to fine tune in game.
Here is a small chart of what cycles equals to what CPU: http://www.dosbox.com/wiki/performance
Anything from 10,000 to 200,000 will equate to about 386 to Pentium which is what you want from DOSBox.

James-F wrote:

In my experience when dosbox exceeds the cycles your actual CPU is capable emulating, the emulation starts to stutter. […]
Show full quote

In my experience when dosbox exceeds the cycles your actual CPU is capable emulating, the emulation starts to stutter.

...

Here is a small chart of what cycles equals to what CPU: http://www.dosbox.com/wiki/performance
Anything from 10,000 to 200,000 will equate to about 386 to Pentium which is what you want from DOSBox.

Two other things are also in play. If you are capturing video, the video capture code is in the main thread, and typically cuts the maximum emulation speed in half (due to having to copy the screen image, and audio a second time.)

The second thing in play is disk speed. For all intents, no dos game should actually be hitting the hard drive, it should be reading from the disk cache in the host OS. But this doesn't apply to using disk images. Case in point, copy files from two disk images on the same host drive inside dos box. It will look like it's doing nothing for a minute or two, and then say it's copied all the files all at once.

When I play games, without capture on, there will be the occasional audio stutter, which I've chalked up to the audio buffer being not quite the right size. But what IS interesting is that if you capture the audio, there is no stutter at all in the captured audio, which means it's more likely the OS is causing the stutter. It would be interesting to find out if OSX or Linux experience the same problem or if it's just isolated to DOSBOX 32-bit on 64-bit Windows OS.

I'm not capturing video or audio, but I noticed changing dosbox priority influences on the stuttering.

Stuttering seems to be gone using max cycles if specifiyng a cycle limit.

yep, during investigation, i found that there are unexplainable jumps in the cycles to 4 times the amount your pc can handle. (which results in the stuttering).
Setting a sensible limit does help against that, if that limit is chosen to be lower that the " wrong" guessed amount of cycles.

When using DOSBox I always use the high performance power plan in windows so that the CPU will not downclock.
When the CPU is stable I can raise the emulated cycles in dosbox to find the maximum emulated cycles my real CPU can handle just by noting at what cycle a game (Quake for example) starts to stutter.
Now that I know the maximum emulated dosbox cycles my real CPU can provide it is much easier not to go over it.

Once again, i always use Fixed cycles in DOSBox for stability and to get an average speed of the emulated CPU like 386, 486, Pentium.

Qbix wrote:

yep, during investigation, i found that there are unexplainable jumps in the cycles to 4 times the amount your pc can handle. (which results in the stuttering).
Setting a sensible limit does help against that, if that limit is chosen to be lower that the " wrong" guessed amount of cycles.

These stutterings didn't happen when I had Windows XP on the exact same hardware. Could it be related to the host OS?

I had a similar issue. I think it started when I upgraded to Windows 7. Anyway I was able to solve it by changing the prebuffer to 80 as suggested in this post by "Old PC Gaming" https://www.oldpcgaming.net/how-to-stop-stutt … usic-in-dosbox/

prebuffer=80 (before I had it set to 20 when it was stuttering)

The current SVN should be a lot better regarding to the stuttering, so the advice you give might not be needed if you switch to that