Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Here's why GUS sound FX are bad.

629 views
Skip to first unread message

Tom Klok

unread,
Sep 11, 1994, 5:25:36 AM9/11/94
to
In article <34u33c$m...@illuminati.io.com>, Hardball <hard...@io.com> wrote:
>
> I received mail from the guy who writes the sound code for DOOM.
> Here's what he had to say about why the GUS sound FX are so scratchy and
> why there's a slowdown from 1.2 to 1.666:

Did you ask Paul for permission to repost this? Anyways...

> --- begin message here ---
>
>> All of the sound effects are now mixed in software, rather than on the
>> GUS hardware.

<sigh>

>> Why, you ask? Because of several reasons. First, is that the GF1 chip
>> has a minimal ramp time that is much to long for very sharp effects.

I don't understand this. If the digital samples are properly normalized
to start and stop cleanly on a null, with a few extra samples to take
care of the interpolator, you don't need to volume ramp them at all.
The GF1 can also ramp very quickly... fast enough to introduce
volume change artifacts.

>> Second, because loading of the MUSIC patches uses all of the GUS
>> memory, I had to DMA all eight sound effects to the card when played.

Which is why I wish we could've had a sfx-only option. It would have
made Doom the finest-sounding game on the planet. At least 14 sfx
sounding at the same time, proper volume and pan effects, easy pitch
shifting, and full interpolation to 16 bits. No CPU load either.
All we'd lose is the music. I really *like* the music, but even so
I turn it right down for deathmatch.

>> This intern exposed a bug in the GF1 chip that Gravis did not find
>> until my code started to beat on it. The bug would cause the bus
>> to freeze and any program with it.

Ouch. Has anyone documented this properly? Btw, my particular machine
doesn't exhibit this with Doom v1.2 and DMA channel 1.

>> The workaround is to keep DMA activities to a minimum by mixing in
>> software and transfering only 1 channel to the GUS.

Well, there goes any hope for quality sound. :(

>> But since the GF1 can't support auto-initialize DMA,

Why not just double-buffer and service the GF1's DMA TC IRQ? That's
the method the SDK suggests.

>> and because the only way to play interleaved data on the card is
>> to set two voices pointing into a single patch and setting the
>> frequency so the every other sample is skipped, you don't get the
>> benifit of sample smoothing from the GF1.

The GUS was never designed for interleaved streams. It's a sample-
playback engine. The above is a rude hack. I can understand the
constraints you're working under, however. Was two streams of
mono via DMA still causing lockups? This seems odd... I know of
other GUS apps that appear to pull it off successfully.

>> Sorry, but that's the way it has to be :(
>>
>> Paul Radek
>> Digital Expressions, Inc.

It better not be that way with Quake! I want an option to screw the music
and let the GUS do what it does best: play samples stored in GUS memory,
not paged in from disk. At the very least, leave a hook in Quake so we
can write it ourselves.
--
Tom Klok MIND LINK! Staff Vancouver BC
tom...@mindlink.bc.ca What, me hurry? -- Alfred E. Von Neumann
GCS/E/O d-- p-- c+++ l++ u e+ m-- s+/ n--- h-- f+ !g w+ t+ r+@ y++@ GUS DOOM!

Hardball

unread,
Sep 11, 1994, 1:03:40 AM9/11/94
to

I received mail from the guy who writes the sound code for DOOM.
Here's what he had to say about why the GUS sound FX are so scratchy and
why there's a slowdown from 1.2 to 1.666:

--- begin message here ---

All of the sound effects are now mixed in software, rather than on the

GUS hardware. Why, you ask? Because of several reasons. First, is that


the GF1 chip has a minimal ramp time that is much to long for very sharp

effects. Second, because loading of the MUSIC patches uses all of the


GUS memory, I had to DMA all eight sound effects to the card when played.

This intern exposed a bug in the GF1 chip that Gravis did not find until
my code started to beat on it. The bug would cause the bus to freeze and

any program with it. The workaround is to keep DMA activities to a minimum
by mixing in software and transfering only 1 channel to the GUS. But
since the GF1 can't support auto-initialize DMA, and because the only way


to play interleaved data on the card is to set two voices pointing into
a single patch and setting the frequency so the every other sample is
skipped, you don't get the benifit of sample smoothing from the GF1.

Sorry, but that's the way it has to be :(

NICK SABINSKE

unread,
Sep 11, 1994, 11:51:15 PM9/11/94
to
Tom Klok (t...@auggy.mlnet.com) wrote:
: It better not be that way with Quake! I want an option to screw the music

: and let the GUS do what it does best: play samples stored in GUS memory,
: not paged in from disk. At the very least, leave a hook in Quake so we
: can write it ourselves.

This 'hook' is most likely going to be the VESA Sound Standard. iD is
keeping the sound code in house this time. Actually, that would be the
VESA code. I seem to remember (somewhere) that iD was doing this. Very
smart after this DOOM sound code licenceing disaster! So Quake will
basically be, if it doesnt work for you then its your driver's fault (as
long as the VESA code is correct in Quake heh)

- TBP

Dave BIGGS - Dave

unread,
Sep 12, 1994, 8:18:54 AM9/12/94
to

Maybe but this is also might be why, this is a bit of a letter I that was
origanally from romero that was forwarded to me by someone else.


__________ starts here __________________


Hey, everybody! Thanks a lot for downloading DOOM II -- that's really "cool".
We love it when we send evaluation copies to magazine editors and some piece of
shit uploads the thing. The DOOM II out there is the master copy we sent to GT
Interactive, our distributor. If your GUS sound doesn't work, it's probably
because your IRQ is > 7. Our sound code dork broke part of the sound support
while he was "expanding" it, so IRQs > 7 don't work, Pro Audio Spectrum owners
now have to run their SB-emulation driver (no more native support), etc. The
sound guy is a real shithead. All these fuckups are in v1.666 as well --
sorry. We have NO time to wait and hope that sound-dork fixes these problems,
as he's demonstrated in the past year and a half that he's incompetent.

_________ end here _____________

It seems that romero doesn't exactly like the "Sound-dork" doesn't it.
Maybe it's his fault that the sound is really screwy

Cya
Dave Biggs


----------------------------------------------------
##### #### #### ### ### "If there's No
XXXXXX XXXX XXXX XXXXXXX Silicon Hell,
XX XX X X X X XXXXXXX Where do
xx xx###########xx x xx all the
xxxxxx x### ###x xx xx Macintoshes
===== =### ###= == == go?"
########### David Biggs.
"Hell On Earth" Da...@halls1.cc.monash.edu.au
----------------------------------------------------

0 new messages