The DOOM sources as originally released on December 23, 1997

linuxdoom-1.10/README.sound

@@ -0,0 +1,110 @@
+
+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.
+