Thank you very much for those recordings. I thought I there were problems with the emulation, but it's supposed to sound like that.

The silent noise in the menus is caused by the game setting the pc speaker output to a very high frequency (like 500 kHz). That frequency isn't audible directly, but I guess it causes distortion in the speaker which makes it slightly audible. Supaplex also does this between the notes of the music.

Currently, in Dosbox, there is protection against setting such a high frequency, because it wastes a huge amount of CPU time. In my patch the output is set high in such a case. Another solution is setting the frequency to some lower value, which makes the noise slightly audible.

edit: Nope and Atom were trivial to fix. They expect the PIT to have been programmed into some mode - they don't do it themselves. They switch the speaker output between PIT output (expecting it to be high) and forced low. Changing spkr.pit_output_level from 0 to 1 in the constructor fixes the demos.

A similar situation can occur in official source because the timer is initially set to mode=3 cntr=1320, but the speaker state isn't set like it would be if the timer was programmed by port writes. So a few games fail to produce "standard" beeps because they don't mess with the timer at all. I've mentioned it to the devs, and I think their intention is to eventually do the initial programming of the timer in the emulated BIOS with port writes (like a real system BIOS would do for POST beeps), which will give the speaker its initial state as well.

By the way, it looks ZZT has working footsteps sfx now (I haven't checked other similar games like Kroz, Castle Adventure, and Caves of Thor but I guess they might have similar problem that may be fixed now too).

I checked the silent sound in Supaplex and it doesn't look like sound rather like a noise.

I also checked Race Driving' (looks like it is Hard Drivin' III). This game also has silent sounds. It has more sound cards support and even pc speaker sounds are better quality so it is possible to recognize that after clicking the mouse you hear starting the engine. (You don't hear it with adlib or roland, and sound blaster doesn't work in this game). So the engine cannot be heard before as it wasn't started yet This game has silent sounds before and after starting the engine and during driving.

There are some problems in Tandy sound mode in dosbox. Hard to say how should it be as I don't have real Tandy computer. The I guess silent sound can be heard and it doesn't sound good as it breaks after you leave the road and doesn't fix when you come back to road. So I guess Tandy sound is not properly emulated, as I guess we shouldn't be able to hear that sound too in Tandy mode. (Although the breaking sound when leaving the road Is somewhat ok as it happens with Roland and Adlib too). However you hear the "broken" sound even before starting the engine. So I don't know what to think about it. Checking on real Tandy PC would be needed I guess.

Voodoo2s aren't 100mhz stockGeforce256 isn't released as a beta on New Years '99 under the Quadro brandDOS gaming isn't a bilinear 320x200 16:10DOS PCs aren't better than the MacintoshDOSBox is not for running Windows 9xSGL != Glide

Good news: I found a bug in my mode 1 implementation, which caused Wizball and Perestroika's whine to be too audible. With the correction, the whine is much higher in frequency, and so less audible, and easier to remove by filtering (once I implement the filter, that is).

Bad news: I looked into how The 3 Stooges generates (tries to generate) sound and I'm baffled. 3 Stooges uses PIT mode 1 for speaker output like Star Control. PIT mode 1 works so that once the mode is set, output goes high immediately. Then the application can write a counter value to the PIT, which doesn't affect the output yet. To change the output, the application can toggle the PIT gate input from low to high ("trigger"), which causes the PIT to output a low pulse whose length is determined by the counter which was previously written. When the pulse is over, output goes high again. If the application causes another trigger while the low pulse is ongoing, the pulse is lenghtened by the current counter value.

3 Stooges triggers the PIT every 31 microseconds (~32kHz). However, the counter values it writes to the PIT are much longer than 31 microseconds (usually over 100 microseconds). This means that due to the constant retriggering, the speaker output stays low all the time --> no sound.

Like Atom and Nope, EGA Battle Chess is also fixed by setting the initial speaker state.

Will Harvey's Music Construction Set: 1-voice output is fine, but 4-voice output is silent with the patch. 4-voice output works in official source, but volume has to be way up to hear it. Setting the initial speaker state doesn't help; and playing with 1-voice output before switching to 4-voice output also doesn't help.

I think it may be useful to notice that 3 stooges is also working with dosbox modified by ripsaw from this thread viewtopic.php?p=163331But sfx are very silent compared to music (unlike other Cinemaware games working with ripsaw's modification)
BTW 3 stooges needs cycles about 300 for sfx not to play too fast.

My initial implementation of mode 1 (that worked in StarCon 1) was incomplete/buggy. It didn't generate some (every other or so) low pulses it was supposed to. Same thing caused louder whine in Wizball and Perestroika.

The Bach Invention in MCS seems to lose some fast notes with 4-voice output; sounds like clicks instead of tones. Don't know if it's accurate or not, but the program is actually pretty good at adapting to system speed, so perhaps robertmo can compare to hardware.

Battle Bugs produces some speaker sounds, but the mission briefings sound like soft white noise instead of the speech you hear with other digitized sound options. Not sure if it's wrong or not, but I've read comments that there should be speech.

When experimenting with filtering, Bad Cat seems like a good test case; the digitized music in its credits screen has a lot of high frequency noise.

Have to tell you that I currently attempt to rewrite the system timer, so the interface to the pcspeaker code may change if it works out.

What kind of a plan do you have for the rewrite? Currently, the speaker code duplicates a large amount of PIT functionality. If it's possible to have the PIT code notify the speaker code whenever the PIT channel 2 output changes, all of the duplicate functionality in the speaker code could be removed. Something like:

I implemented better interpolation/filtering. Now Hard Drivin' 2 intro sounds pretty good. Perestroika intro also sounds almost exactly the same as the real thing. The improvement is mostly audible in games that use the PC speaker for outputing digitized sound.

If you can hear a high-pitched whine in such games, you can get rid of it by using a lower pcrate in dosbox.conf (16000 for Wizball for example, 32000 for StarCon2 and Perestroika - you should also lower mixer rate to match).

There are some lingering issues. First of all, when playing, you might hear slight crackling. However, if you capture the sound with Ctrl+F6, you can't hear it in the captured version. This leads me to believe that the callback with the new filtering takes too long to execute sometimes.

The second issue is that for speed reasons, I had to use a lookup table for the filtering, instead of evaluating the "impulse" function directly. This leads to worse sound quality compared to the reference implementation that doesn't use the lookup table. Also, there's some hidden bug in the lookup implementation, because if I increase the lookup table size to increase quality, it breaks completely.

The final issue is that the mixer sometimes request more samples that I expect it to. There's a hack for that, but it results in a couple of "too many samples" prints when you start up dosbox. The pc speaker code assumes that the mixer callback is called every emulated millisecond. I don't know how the mixer works, so I don't know if that assumption is correct.