That's interesting - is it the slow ISA bus that's the difference? If you did the benchmark again with the bus at CLKIN/4 for example, would the ACE perform better (despite sounding worse)?

Doom's GUS drivers perform all sound effects mixing in software, uploading the result to GUS RAM. Hence why it's no faster than the SB.

Doesn't DOOM do 16 bit mixing when using a 16 bit sound card? If this is done in software it might explain the difference. You could try a Sound Blaster 16 to test this. (The command line parameters don't seem to have an option to force 8 bit mixing.)

According to
http://www.complang.tuwien.ac.at/misc/doombench.html
your score with the SBPro is not too far off.

Regarding ISA clock speed: When my family had a 386-40 the standard divider was /6 (about 8.3MHz), but I could also set it to /5 and /4 which increased ISA bandwidth. We had a Paradise Card (WD90C31) which in retrospect has to be one of the fastest ISA VGA cards. (Bandwidth in MB/s roughly equalled clock frequency in MHz, timed with my own benchmark routines.)
DOOM was playable on that machine as long as you either reduced graphics detail or screen size.
(Doesn't apply in your case since you are using a VLB card.)

Okay, with a Sound Blaster 16, I get 2694 realtics or 27.84fps. I don't think the game is mixing 16 bit sound, at least with a Sound Blaster, since it does not use a High DMA channel. Oh, in this test I was using CLKIN/4, since Sound Blasters and DOOM can work harmoniously at that speed.

In an earlier post, I stated that I could not get DOOM working properly with a GUS ACE with CLKIN/4, the sound would stutter horribly. I tried my BIOS's setting of 7.159MHz, and that seems to eliminate most of it. However, it seems that CLKIN/5 is a better setting for the game.

CLKIN is 33MHz in my machine (as I am running a 486DX2 @ 66MHz, clock doubled), so CLKIN/4 = 8.25MHz and CLKIN/5 = 6.6MHz.

I think the inescapable conclusion is that DOOM's sound drivers were not well-optimized for the GUS.

Just for fun, I put my IBM 8-bit VGA card inside the same system and ran the benchmark with Sound Blaster Pro for music & fx. 27948 realtics or 2.68fps was the result!

There are settings in my BIOS for Latch Local Bus and Local Bus Ready.

Latch Local Bus has settings T3 and T2.

Local Bus Ready has settings Synchronize and Transparent.

The bold option is the default, but after reviewing the BIOS companion it seems the alternate options offer better performance for VLB video cards. I haven't encountered any stability issues yet.

My new benchmark result for DOOM 1.9s, timedemo 3, is as follows :

realtics :
No Sound or Music - 2288 (or 32.78fps)

I expect that is pretty much all you can squeeze out of this system. All other settings were at the fastest possible speeds. DOOM is extremely playable.

That's a great result. I have a similar system which I was only able to get down to ~2800, it might have done 2600 without sound. Nothing I did in the bios seemed to have much of an effect. I see your chipset is an SIS and mine's a UMC, I wonder if that's the difference.

I've since installed a drive overlay to access the full 6 gigs of the hard disk I put in it, and now it can only push ~3100tics. Still pretty playable.

I tested the benchmark in the same system with a new video card, a Cirrus Logic GD-5429 VLB card with 1MB of RAM. The new result is as follows :

realtics :
No Sound or Music - 2262 (or 33.02fps)

Since the fps calculation is realtics/gametics * 35, the maximum framerate for DOOM seems to be 35fps, exactly half of the VGA refresh rate of 70Hz. I doubt that the 35 frames per second figure was chosen at random. I think that by using half the refresh rate as the frame rate, they were trying to avoid screen tearing while maintaining an relatively achievable framerate with then-current hardware.

doom benchmark is a bit strange for me... i could never push it much higher than 200fps despite using some modern computers, with sound off of course. and i wonder what OS the top scores on the list(360fps with celeron800, and 450fps with celeron1.0 etc) are using.
rigs i tested:
815e+p3s-1.4g
nforce3+k8-3500+ oc 2.56
pt880+e5200 oc 3.33g
p45+e8400 oc 3.6g
doesn't make much difference, all in the range of a bit more than 200fps.

Here goes a necropost 😀
Doom has no tearing because it uses triple-buffering and has always-on vsync. 70 FPS was not feasible back then, but 35 perfectly achieveable on DX66/DX2 80 with VLB videocard, so Doom is 35 FPS locked. Mode X drawing routines used in the original Doom (but not Heretic) make reaching perfect framerate pretty much impossible with High Detail on ISA videocards. Use of ISA videocard implies low detail mode for optimum performance in the original Doom/Doom II.

noop wrote:

Here goes a necropost 😀
Doom has no tearing because it uses triple-buffering and has always-on vsync. 70 FPS was not feasible back then, but 35 perfectly achieveable on DX66/DX2 80 with VLB videocard, so Doom is 35 FPS locked. Mode X drawing routines used in the original Doom (but not Heretic) make reaching perfect framerate in pretty much impossible with High Detail on ISA videocards. Use of ISA videocard implies low detail mode for optimum performance in the original Doom/Doom II.

Strange that back in the days when I had a fairly fast system (ALI1487/89 based 5x86-133, running at 150-160) and a ungodly slow VGA (Tseng ET3000 maxing out at ~1500chr/ms in Landmark) Heretic ran MUCH smoother than Doom. Low detail helped a bit, of course but I'm not sure it could ever surpass Heretic's render-in-system-ram-then-transfer-the-frame approach.

On the main topic - I haven't tried to benchmark Doom with sound but I've encountered huge speed impacts with GUS Classic (Max/PnP codecs work pretty much like an SB) in Quake too. And it seems that it's motherboard or chipset dependent. Among the ones I tried i430TX, ALI Aladdin 5 and i845 did certainly suffer from this phenomenon, turning on GUS sound yielded a ~30% performance drop. On the other hand, SB16 had much less impact.

Other chipsets like i440BX or VIA Apollo versions (I tried KT133A and 694T) didn't show this dramatic performance loss with GUS streaming, GUS Classic performance didn't fall too far behind SB16 with these.

These are fairly late ISA chipsets but it seems that this problem started much earlier.

Afair Doom's sound engine only does software mixing even with GUS cards.

Vallenrod wrote:

Afair Doom's sound engine only does software mixing even with GUS cards.

As does Quake. Quake even goes up to 19.3kHz from the default 11 to match the GUS' internal mixing frequency. It still can't explain the massive performance loss (the extreme case being 30% of a Northwood-3066/512) against the SB which works with software mixing too.

What are the SB/GUS FPS with sound only and music only?

Plasma wrote:

What are the SB/GUS FPS with sound only and music only?

Just one example, the resolution is 640x480. From an i845 board, with the aforementioned 3066/533 P4, single channel DDR-333, PCI Asus V3000 (because the industrial backplane didn't have an AGP slot. Now I have a Soyo ISA/PCI/AGP board but DOS performance didn't improve much with AGP):

1Nosound  102.6 fps (100%)
2SB16      95.5 fps (93%)
3GUS       63.5 fps (62%)

alvaro84 wrote:

As does Quake. Quake even goes up to 19.3kHz from the default 11 to match the GUS' internal mixing frequency. It still can't explain the massive performance loss (the extreme case being 30% of a Northwood-3066/512) against the SB which works with software mixing too.

It probably has to do with the fact that the SB just has a simple DMA-driven DAC, where the GUS has a wavetable synthesizer.
So in order to 'just' play a sample on GUS, you first need to upload it as an instrument, and then trigger a note.
There's probably considerably more overhead involved here. It's just not what the GUS was designed to do.

Scali wrote:

So in order to 'just' play a sample on GUS, you first need to upload it as an instrument, and then trigger a note.
There's probably considerably more overhead involved here. It's just not what the GUS was designed to do.

Basically it's true, playing a stream is a bit more complicated on the GUS. But it can upload via DMA, and the note can be looped too. Now I'm not sure if an IRQ can be triggered when it goes past a certain sample (I've only coded a small wavetable based mod player for it) but it should. So once you set up a channel to play a double buffer you just have to initiate a DMA transfer every time your channel exceeds a buffer boundary. It isn't much more troublesome for the CPU than having the SB play its system RAM buffer(s).

Also some chipsets don't suffer from this performance loss.

alvaro84 wrote:

But it can upload via DMA

DMA says nothing about the speed though. Heck, only very early PCs used DMA for the harddisk, because on 286 and newer machines data transfer with CPU polling was much faster than using DMA 😀
It could very well be much slower at uploading than an SB is playing samples in realtime.

alvaro84 wrote:

Also some chipsets don't suffer from this performance loss.

That is interesting... If it indeed uses DMA, then perhaps there is an issue with the handshaking, which makes some chipsets much faster than others?

alvaro84 wrote:

Vallenrod wrote:

Afair Doom's sound engine only does software mixing even with GUS cards.

As does Quake. Quake even goes up to 19.3kHz from the default 11 to match the GUS' internal mixing frequency. It still can't explain the massive performance loss (the extreme case being 30% of a Northwood-3066/512) against the SB which works with software mixing too.

With AWE32, sample upload is software, and not very fast. Possibly same on GUS, and possibly you are even forced to send 16-bit data through 8-bit ports. Didn't program GUS though. On EMU8000, where writes are always 16-bits, 1MiB of data takes roughly 1 second to upload. Situation with sending 16-bit PCM via 8-bit ISA accesses(with delay!) exists, for example, on Adlib Gold MMA, which I recently studied. Basically, the speed of such uploads does not scale with CPU speed at all.
I suspect software mixing is used with GUS in order to not compromise sample RAM and channel count required for music playback.