Some more details: fiddling with the [mixer] vars rate blocksize prebuffer alters the problematic behavior, but does not fix it. The music plays for 20 seconds and then dies.

Since the problems persist when changing the game soundcard (SB/GUS) I deduce the problem must lie in the way dosbox uses windows sound interface.

I hope one of DosBox developers, who contributed to the sound interface, will see it and respond.

Zarn wrote:

I deduce the problem must lie in the way dosbox uses windows sound interface.

I do not know why you would deduce that, since otherwise there would be many more people reporting a similar problem with many more programs. Are you having sound problems with other games yourself?

This problem was brought up once a few years ago, but there is no clear answer there either, unfortunately.

Zarn wrote:

Since the problems persist when changing the game soundcard (SB/GUS) I deduce the problem must lie in the way dosbox uses windows sound interface.

I deduce the game may have poorly programmed sound. Anyway, did you try the different Sound Blaster types?

I did try the different soundblaster types. Just as with GUS there is simply no effect to the card chosen.
Just now did I note that the DosBox status window actually outputs illegal memory writes:

Illegal read from 1f002bd, CS:IP 180: 345c2c
Illegal read from 1f002be, CS:IP 180: 345c2c

There are hundreds of these... can it be the game assume the sound card/driver has more memory than it actually has?

The reason I am fairly sure this is a DosBox issue is that I actually own the game for decades by now. It had no such problems, ever, with the real sound cards I used over the years, from the original soundblaster, through sb16, original GUS, PCI GUS, SB Live... the list goes on. I never had sound problems once the blaster= and ultradir= were correct.

OK, I'll try to shift the SB meme base to different addresses. Wish me luck.

Wait a minute, 1f00... that's beyond the 32Mbytes threshold! Am I right?

False alarm. With 16megs there is no error output, but the problem persists.

The plot thickens
Changing the machine= var changes the problematic behavior considerably. Maybe this is actually a write-to-[wrong addr]screen problem

No machine= setting works. With some, Dosbox crashes on game init.

OK, I fixed it, though I have no fucking clue how. One step was to get the game install.exe to work. It requires VESA, so I took one of the 2 VESA machine types, also fiddled with some screen settings. Pehw.

So the priblem was that you didn't install it in dosbox?

(Btw, it doesn't matter if you have a real GUS, since dosbox emulates it and doesn't use the real one anyway - just thought I mention it since it sounded as if you had assumed dosbox would use the real one)

I'm not sure - but that is most probable. During the install it does ask for target dir, and I cannot be sure the directory in DosBox matches the PREVIOUS install.

As for the GUS, I know DosBox emulates it, and quite well, however there are some "quirks" I loved that the emulation does not replicate. It may sound weird, but I realy loved my GUS, that proved itself superior over more than a decade. I should frame it and hang it on the wall or something.

After tinkering with Master of Orion II sound problems i found that output=opengl produce sound stutter with orion after a while. With surface or directdraw output with fullscreen or windowed mode sound is fine. Also - with opengl output then you quickly move mouse cursor sound WILL stutter bad - none of this with surface or directdraw output. Generally opengl output will affect sound then you move mouse. This also affect Crusader games and many others.