I gave the idea some more though and I realize I could make that p1-233mmx downclocked at 120mhz struggle to run the game by disabling both level cpu cache. According to norton SYSINFO, it should compare to something like a 386DX-20~25mhz. At maximum screen size, high quality DOOM draw around 5fps. At this level of performance I imagine the offloading of the music mixing would have a tangible effect. Level E1M8 music seemed to be the most complex, at some point 9 midi channel are used, not counting notes and drum addition. So I proceeded to record a demo of this level which also has the advantage to begin in an empty room where I would only spin in circle, enjoying that all time favorite masterpiece. I don't want to test the sound effects now.

I playback that demo 4 times, using the ultrasound music and no music on version 1.1 and then same audio procedure with version 1.2. According to the faq, to determine fps you need to use the formula (GAMETICS/REALTICS)*35, so I added that value on the table. I added 1.9 for verification :

1						gameTics,	realTics,	fps
2doom 1.1 UltraSound :		1421	,	9338	,	5.32
3doom 1.1 NONE :				1421	,	7743	,	6.42
4doom 1.2 UltraSound :		1421	,	8628	,	5.76	
5doom 1.2 NONE :				1421	,	7652	,	6.49
6doom 1.9 UltraSound :		1255	,	9493	,	4.62	
7doom 1.9 NONE :				1255	,	6808	,	6.45

The impact of software rendering don't add up to me, it's way below my expectation. If we compare the pure engine using NONE sound we have a 0.07fps in difference between the two version. So if we keep that in consideration and substract it to the UltraSound difference in both version that give a 0.37 fps difference, which represent as few as 6% gain using the UltraSound.

I don't think the music quality change enough to consider they used low quality rendering. And the impact is too minimal for such a slow cpu. Maybe a dump of the GUS RAM after a game would help understand how they used it. The FAQ mention lockup using the GUS on the 1.2 version and the impact drop significantly on 1.9, so maybe they fallback to software on another version? It is also unclear if they only used software playback for the music. Each time I read about the problem they faced with the GUS, there is only mention of the sound effects.

It's better to test with the detail and screensize to the minimum, as the drawing routines are taking all the cpu time compared to the sound code (just adds 15-20% to the cpu usage), this way the differences would be much bigger. The sound code in Doom and the DMX library are very very messy, i'm pretty sure they disabled hardware mixing after the 1.2 release.

The DMX plays the music using samples stored in the sound card memory, the software mixing only affects sound effects. I guess Doom 1.1 and 1.2 stores sound effects in the sound card ram, plays them whenever needed, and replaces them when the memory gets low, and the later versions upload the sound effects already mixed in software to the sound card memory (like a small buffer).

Maybe you can test also with FastDoom and see how it performs with the GUS (edit: FastDoom uses software mixing for the GUS)

Thanks for your input ViTi95. I continued my research and I think I can confirm that Doom and it's DMX engine never used software mixing for the music, what a relief. I did a dump of the GUS memory and all music patch are here, that and impact of using a GUS from playback allow me to be fairly certain the GF1 was always used to render the music for the game.

With that in mind I can re-read the faq

DOOM FAQ wrote:

Bug fixes since v1.2:
- Sound code rewritten.

and this very helpful post by gerwin and understand I was just too quick to assume the music would inherit the same sound FX treatment.

On the 1.1 and 1.2 dump there is a ~6kb free space at the start of the ram, on the 1.9 it seem to have grow to 8kb. My guess is that Paul Radek might have used that space to manage the sound FX using different implementation over time.

ElBrunzy wrote on 2021-07-15, 06:41:

Thanks for your input ViTi95. I continued my research and I think I can confirm that Doom and it's DMX engine never used softwar […]
Show full quote

Thanks for your input ViTi95. I continued my research and I think I can confirm that Doom and it's DMX engine never used software mixing for the music, what a relief. I did a dump of the GUS memory and all music patch are here, that and impact of using a GUS from playback allow me to be fairly certain the GF1 was always used to render the music for the game.

With that in mind I can re-read the faq

DOOM FAQ wrote:

Bug fixes since v1.2:
- Sound code rewritten.

and this very helpful post by gerwin and understand I was just too quick to assume the music would inherit the same sound FX treatment.

On the 1.1 and 1.2 dump there is a ~6kb free space at the start of the ram, on the 1.9 it seem to have grow to 8kb. My guess is that Paul Radek might have used that space to manage the sound FX using different implementation over time.

I would have been surprised if the people behind DMX had actually bothered to write a software synth that just happened to
a) use .pat files (Gravis patch format)
b) be able to run on a 1993 vintage 386/486 at the same time as the Doom graphics engine
c) have done a and b only for the benefit of Gravis Ultrasound users

I may be remembering incorrectly, but I was under the impression that Doom used an integrated version of UltraMID. In most versions, this reserves 8 voices for digital audio/effects, and uses the remaining 24 for MIDI-based music. I don't remember if that could be changed.

Other than the instrument mappings, which I believe the id people changed over time, the actual MIDI playback code was likely intact, as released by Forte Technologies. They could in theory have played up to eight channels of effects using hardware mixing, but likely decided that using the same sound mixing and playback code over two voices was easier/faster (in terms of development time, not game performance), rather than having a separate set of routines optimised for just one card. Maybe this is the change that is being observed across different versions.

Really, using UltraMID was the easy way out, rather than having proper GUS support, but we don't know what the constraints (time/memory usage) were.

The DMX library doesn't use UltraMID, even not a single external library is used to drive the GUS. All support was made in-house. Also the Doom code doesn't know how to play the music, it just sends the lump data to the library. I think they switched to software mixing due to hardware bugs, the loss in performance is very noticeable.

Edit: I'm pretty sure that the software mixing was enabled in the 1.4 release, there are some mails from 1994 talking about sound bugs with the GUS. Mainly, worse audio quality with noises and scratches and lower performance.

darry, I agree it would have be far fetched but not impossible. During the timeframe of 1.0 to 1.9 I went from a 386sx16 to a 486dx50, they could had sneaked in software playback hidden behind a bug and a compatibility problem 😉. They where using a sound engine from a third party, and software engines started to emerge already like MIDAS and BWSB. They would also had the patch set already deployed for the owner of the soundcard. For those reasons I could see it happen and I wanted to make sure it did not. On my first post I mentioned a 386dx40 I had in between the 386sx16 and 486dx40 conflicted with some of the game version due to NMI problem so it was hard for me to appreciate the change back then.

640k!enough, it would make sense they used an integrated version of Ultramid as people that made GUS patch fix WAD observed similarity when analyzing the DMXGUS resource:

GUS1M.TXT - Tom Klok wrote:

I was curious about the internal format of MUS files, and pretty happy when the MIDI2MUS utility was released. Thanks, guys! M […]
Show full quote

I was curious about the internal format of MUS files, and pretty
happy when the MIDI2MUS utility was released. Thanks, guys! Mucking
around with the original D_* MUS files Doom is supplied with, I
decided to compare the patches they used with the DMXGUS file to see
what kind of mapping was going on. It turns out there's a lot of it,
but much of it is poorly set up. id's supplied DMXGUS file is almost
exactly the same as the ULTRAMID.INI file supplied with Ultramid 2.00.
That's a good shot at a generic GM mapping, but Doom never uses many
of the loaded instruments... and many of the instruments it DOES use
are mapped to something else.

I can confirm that what he say is true and it explain the weird things I found in the GUS RAM dump of 1.1/1.2 (fixed on 1.9 probably due to 1.4,1.5 mapping improvements). What I hate with Ultramid is that you cannot balance the number of active voices versus notes priority. We don't know how the doom engine allocate its resources but we can imagine that if they now use 2 channels for FX software mixing instead of the four they originally used, that would free them for the music, but I doubt they made that kind of optimization.

ViTi95, I'm not sure either they made the switch for software mixing effects on 1.2 exactly, I have not given much attention to it as I was concerned about the music. All I know now is that the SB, PAS and GUS have 4 voices on 1.1 and 1.2 but all goes up to 8 on 1.9. I did some close listening comparing the 1.1, 1.2 and 1.9 as E1M8 is also a good place to test the FX mixing quality with all the pinky inside the circle of exploding barrel at the level start. While 1.1 and 1.2 sound about the same, The 1.9 noticeably sound more software'y and the impact on fps is sensible. Maybe if I have the time I could hunt more version and try to pin when this happen by benchmarking some -timedemo.

It's a shame those details of the DMX engine where lost but it make you realize how hard the GUS was to implement when the game would share a soundtrack with other synth types so it made sense to use a third party solution like AIL or some Ultramid implementation.

ElBrunzy Well not all the details of the DMX library are lost, in fact if you search in Google you can find it's full source code for multiple versions of the library (which is confidential).