At a first glance:
the only change to the auto-cycles that has an effect (on my pc! )
is the change from >= 1000 to >= 250 in the line
if (CPU_CycleAuto && (ticksScheduled >= 1000 || ticksDone >= 1000)) {
Indeed this does avoid most of the sound stuttering experienced with
some games for me.

auto-cycles still has problems with opengl+vsync where the cycles drop
down to zero, unless this is resolved, the auto-cycling to a fixed cycle
value (CPU_CycleSet in the patch) isn't an option.

The patch breaks the singlestepping of the heavy-debug enabled
dosbox debugger, should be easy to fix so don't bother.

Not quite; the trick is also checking ticksadded, which indicates a large cycle change when a game quickly pegs the cycles. ~250 is also needed lest lag starts creeping back in(more and it takes too long to raise the cycles again after a spike).

I added a cap to minimum cycles. I ran into zero cycles on startup that was causing a startup delay. You'll see it capped to 500 in the patch.

Tinkering, with the titlebar.. I don't like running blind with "auto." What's the desire for doing so? Put another way, why don't you want the title bar being updated once a second with cycles and fps? I think most people prefer to know what's going on. If preference is the issue, the solution sounds like a config option.

( In Reactos it takes a loooooong time to redraw the title bar 😉 )

It... only... happens... once... a... second ... and it sounds like Reactos is in dire need of a rewrite:)

> Not quite; the trick is also checking ticksadded, which indicates a large
> cycle change when a game quickly pegs the cycles.

That makes sense, but it wasn't really needed for the games i tested.
Maybe other people can report if replacing that one line with the one
you proposed solves the sound stuttering for them.