core dynamic and more cycles

Maybe

cycles=max 80%

(which will leave CPU cycles to do the sound emulation)

robertmo, thanks but I'm already using the dynamic core, and adding more cycles makes the game too fast, as I wrote.

MiniMax, I tried your suggestion, also with lower numbers. The result was the same as for plain cycles=max: stuttering in the intro and a game that runs too fast to be playable.

I also tried using the normal core -- without success.

Thank you two anyway for your help.

You mentioned trying a larger prebuffer, but have you tried increasing the blocksize= setting?

You might also try messing with the video settings in case it's an issue for the video hardware being too weak. Try fullresolution=original (I think) and scaler=none, and try different output= settings with it.

Let me throw a theory into the discussion. I don't know the game, but what if the "synching" is just a figment of imagination? I can remember only a handful of DOS games that had more or less good synching (LucasArts adventures come to mind). I mean, many DOS machines had a hard time playing videos at all, not to speak of perfectly synchronizing video to audio on a multitude of possible hw/memory configs, without some sort of common API.

EDIT: ah, i've missed an important part of the original post. My theory could explain a small a/v discrepancy, not what the op has described.

I've found the culprit. It was fulldouble=true.

With fulldouble=false, things work very well.

Howver, in the course of experimenting, I found a couple of strangenesses:

fulldouble doesn't seem to be compatible with output=surface. The screen was very messed up.

Only output=ddraw will scale up machine=vgaonly mode 13h output to 800x600 with aspect=true and scaler=none. The other hardware-accelerated output= options will leave a black border, seemingly using 640x480 only. This behaviour disappears with machine=svga_s3.

The ddraw scaled output looks much better (less mushy) with machine=vgaonly than with machine=svga_s3.

In short, there seem to be a bunch of strange interactions between the various options.

vgaonly uses the 16bpp color mode which results in the effects you observed. The scaler code for the non-working output modes is not ready for that.