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!
--- 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 :(
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
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
----------------------------------------------------