README.sound

README: sound in DOOM


1) DOS/Win32 sound

id licensed a third party sound library called
DMX for DOS DOOM. The situation exhibited
many symptons of serious NIH "Not Invented Here"),
and one of the consequences is that the original
DOOM sound code does not work without DMX. As
DMX is not publicly available, the original DOOM
sound support is removed.

Win32 was not supported in the source dump I got.
I have no knowledge how the WinDOOM port did the
sound handling. A Win32 port should probaly rely on
DirectSound. So far, the Win32 glDOOM port Jim Dose
is working on has no sound support.

In consequence, the only target with a working sound
code is UNIX, which I could only verify with Linux
on Intel586.

2) Linux sound

DOOM for Linux used a separate process, sndserver.

Quoting Dave Taylor:

"Sound drivers should be an asychronous model, either
a seperate thread or a seperate process.  This is
because sound should always be fed to the card without
interruption or else you get pops and with low latency
or else you get angry players.

Now it turns out that this kind of code isn't too fun
to write. In the days of Linux Doom, threads were not a
happnin thing in Linux. In fact, they still largely
aren't. You can use them these days if you have gnu's
libc installed, but you still can't debug them because
gdb doesn't support them properly yet. I believe the
original seperate process had a bad latency delay
because of the time it took for commands to be flushed
through the pipe used to communicate with the seperate
process.  I should have looked into this more thoroughly.

In Quake, I discovered that I could feed multiple
acknowledgements to a SoundBlaster or compatible without
any side-effects such as pops or other malfunctions. 
This discovery led me to switch to a completely synchronous
model, much much easier to debug and understand, so I
think this was fairly intelligent.  Although we had to
populate the game with calls in the right places to keep
the sound buffers fed, and although it wasn't gauranteed to
be always fed, well over 99% of the time, it was fed, and
your the latency was never worse than the frequency of your
refills (several times per frame) plus a small lead time
(40th of a second?)."

The separate sndserver code base introduced some redundancy
(WAD access for sound lumps) for each UNIX target (Sun, SGI,
Linux) and more differences between DOS and UNIX version.
However, I kept the IPC based parts in the source, and
separated the sndserver target in another directory to avoid
further redundancy. There seem to be a few bug-like things
going on in the sndserver that do not receive penalty as
the program has to do only a simple task. One example would
be a libc realloc mixed with zone memory allocation. 

Ungraceful and untimely demise of Linuxdoom (core instead
of I_Error) will leave idle sndserver processes in your
system, blocking /dev/bsp. Kill them manually.

I put the non-redundant parts of the sndserver program
into the i_sound module of doom, and with the SND_SERV
compiler switch you can choose to use the internal sound
support. However, there is a problem with e.g. the
double shotgun and the plasma gun - walk up to a wall,
face it straight, and fire. The sound output is crappy.
This vanishes with decreasing screen size. A similar
problem occurs with trimer driven asynchronous output
enabled by SNDINTR.

I agree with Dave that threads would be preferable.
With respect to Linux ports of John Carmack's next
Trinity engine, this one will rely on Win32
multithreading e.g. for input sampling. So the Linux
community will have to sort out threads anyway :-).

To improve the current sound server, other means of
IPC should take care of the latency. The mixing
buffer/command buffer as shared memory comes to mind.



3) Music support

There is, and was, no music support in Linuxdoom. Fine with
me - I wouldn't give a bat's tail feathers for DOOM music.
Your mileage may vary. There are a few leftovers of the DOS
music support also interfacing DMX, so there is a place
to start. However, in the age of CDROM based music, I
recommend getting e.g. Workman to cooperate with DOOM
(currently, DOOM accessing the soundcard SpekerOut
interferes with Workman controlling the CD drives
SpeakerOut), so musci could be chosen and run completely
independend of the game. You could try Linuxdoom with
Q2 music that way.