Game is probably expecting a different IRQ for sound card. Are you using SB? Try changing IRQ to 5 inside dosbox.conf.

The game's setup program asks what IRQ, DMA, etc, I am using and gives me choices for sound cards like SB16, SBpro, Thunderboard, Waveblaster, General midi for the music or speech functions. I tried as you said anyway, IRQ 5, then tried every combination of music and speech boards (as the game calls it) and still has the same results. Previously I did the same thing with IRQ 7. 😢

When you have problems, one of the first things you should always try is using a default conf file. I was able to cause sfx to stop working on my installation of this game by setting memsize=64 (as you have it), so setting it to the default of 16 should fix your problem.

Maybe it would be a good thing to have a warning on memsize description in the conf file not to change it unless necessary. 😒

Well if stupid people feel it's a good idea to change that setting, it's their problem.
It's just that we have to tell them that they're stupid and so...

ripsaw8080 wrote:

Maybe it would be a good thing to have a warning on memsize description in the conf file not to change it unless necessary. 😒

and then when their game runs "slow" they'll bump it from 16 to 64 (or actually 128 or 256...) anyways because they think it's like Windows and it will make their game run faster. (Because it's "necessary")

The warning would have to apply to every setting in DOSBox.

A default configuration implies that that is the best default configuration and as such shouldn't be changed unless necessary.

1# memsize -- Amount of memory DOSBox has in megabytes.
2#            More than 16 rarely improves performance, and can cause problems.

Some default settings should be left alone more than others, and a simple sentence like this could prevent people from following the misconception that "more must be better", thus avoiding a frequent mistake. My opinion is that it has a very good benefit-to-cost ratio.

DOSBox.conf isn't a wikipedia article or a troubleshooting document.

Any type of notice on the potential risks or benefits of changing .conf settings should be in a seperate document, not in the configuration file.

Maybe adding a warning in the console for mem>=32mb.

Perhaps you'll volunteer to remove the existing cautionary notices on some of the setting descriptions, then, if they bother you so much. People will look at the readme, post in these forums, or troubleshoot in some other way, only AFTER making the mistake. The idea is to prevent a frequent mistake BEFORE its made.

Edit: @wd: that would be good; at least they are warned right up front.

ripsaw8080 wrote:

Perhaps you'll volunteer to remove the existing cautionary notices on some of the setting descriptions, then, if they bother you so much.

Perhaps you'll provide examples of the existing cautionary notices on some of the setting descriptions.

People will look at the readme, post in these forums, or troubleshoot in some other way, only AFTER making the mistake. The idea is to prevent a frequent mistake BEFORE its made.

People WILL bitch on their own forums.
People MAY post on the VOGONS forums.
People MAY read the README after being told to on the VOGONS forums.
People MAY troubleshoot their issue after severe prompting from VOGONS crew.

Fixed that for ya. 😀

The only way to prevent a mistake BEFORE it's made is to beam information into a persons head. If you can do that then you'd better patent it.

Edit: @wd: that would be good; at least they are warned right up front. I must admit I usually hide the console window, though.

It's more like a warning from behind ran than right up front. 😉

DosFreak wrote:

Perhaps you'll provide examples of the existing cautionary notices on some of the setting descriptions.

1# cycles -- Amount of instructions DOSBox tries to emulate each millisecond.
2#           Setting this value too high results in sound dropouts and lags.
3
4# rate -- Mixer sample rate, setting any devices higher than this will
5#         probably lower their sound quality.
6
7# blocksize -- Mixer block size, larger blocks might help sound stuttering
8#              but sound will also be more lagged.

DosFreak wrote:

The only way to prevent a mistake BEFORE it's made is to beam information into a persons head. If you can do that then you'd better patent it.

Even if you could beam the info in there, people still might not act on it. 😉 But seriously, the information can get into their brain using written words if they bother to read them. Just because a measure for preventing a mistake is not 100% effective on every person, that does not mean it has no value. Would the OP have never made this thread if there was such a warning? We'll never know, but there would be at least a somewhat better chance of it not happening. And if the mistake is made anyway, we could also add "you were warned" to any other standard berating done in such cases. 😀

Okay, changed the memsize to 16 and it works perfectly! Thanks for the extra info about the memsize settings. I didn't realize I was being "stupid" and such... I thought it was a good thing to give a program more memory than it would need. I guess I was sorely mistaken and very good info anyway! Thanks DosBox wizards! 😁

Ripsaw: Very good idea about using a default .conf file when I run into problems. That's one of those super obvious things one tends to overlook... or I do. 😊

ripsaw8080 wrote:

[…]
Show full quote

DosFreak wrote:

Perhaps you'll provide examples of the existing cautionary notices on some of the setting descriptions.

Copy code to clipboard

1# cycles -- Amount of instructions DOSBox tries to emulate each millisecond.
2#           Setting this value too high results in sound dropouts and lags.
3
4# rate -- Mixer sample rate, setting any devices higher than this will
5#         probably lower their sound quality.
6
7# blocksize -- Mixer block size, larger blocks might help sound stuttering
8#              but sound will also be more lagged.

The above examples are needed due to DOSBox emulation.

There were sound quality issues with DOS on real hardware as well but most people didn't give a crap and those that did bought the better hardware. Due to the fact that DOSBox is emulating the hardware and also has to rely on crappy drivers/hardware then the comment is probably needed. (Although if you read various forums you'll still see that people needing suggestions to try changing the values.....)

Your comment on memsize is not appropriate for DOSBox.conf because it's not a DOSBox problem. It's a game problem. If we were to add comments to all DOSBox.conf for all game problems then DOSBox.conf would be so bloated as to be unuseable and if we thought people wouldn't look at it before they definetly wouldn't look at it then.

Your comment on memsize is not appropriate for DOSBox.conf because it's not a DOSBox problem.

True but my general feeling is that people change this very value because
they think raising it means faster games. I think currently there is only one
game that for some strange reason works with =64 only, but i neither remember
nor ever debugged it (don't have it).
So imo some warnings are in place about that dosbox.conf entry so people
better leave it alone.

In general i'm not sure if there should be (much) more comments in dosbox.conf,
or rather some additional information in the readme that crosslinks to the
dosbox.conf texts or so. Maybe when reworking the sections for some next
version that can be extended/clarified at the respective places.

Very good idea about using a default .conf file when I run into problems.

The troubleshooting section of the README exactly tells you this as one of the
very first steps btw.

I didn't realize I was being "stupid" and such...

My hope is that using the word stupid a lot makes people think next time they
change some values.
Do you remember why you changed the memsize? Was it recommended somewhere?

KiwiStalk wrote:

I didn't realize I was being "stupid" and such... I thought it was a good thing to give a program more memory than it would need.

Good example of why some increased user awareness would be helpful, however it is accomplished. 😉

KiwiStalk wrote:

Hello DosBox wizards. I was hoping you guys could help me out on this one. Its been stumping me and I can't figure it out:

I got the old Privateer "gold" CD or whatever that has the game, the expansion pack, and the speech pack. After installing and configing, the music plays just fine but the sfx don't come on nor does the speech. In fact, when the game tries to play a sfx or some speech the music gets a little quieter and a little "crackley". I tried changing the mixer, sbtype, and opltype settings and changing the core to normal but none of that helped.

despite the fact that this is an old topic, I still write
I have a problem on Win7 x64 with the privater crackley sound
and the problem was solved by setting
mpu401 = uart