mirror of
https://github.com/ZDoom/gzdoom.git
synced 2025-05-06 09:10:42 +00:00
110 lines
4.3 KiB
Text
110 lines
4.3 KiB
Text
|
|
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.
|
|
|