![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to readme.sound CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [DOOM] / doom|
Return to readme.sound CVS log | Up to [DOOM] / doom |
1.1 root 1:
2: README: sound in DOOM
3:
4:
5: 1) DOS/Win32 sound
6:
7: id licensed a third party sound library called
8: DMX for DOS DOOM. The situation exhibited
9: many symptons of serious NIH "Not Invented Here"),
10: and one of the consequences is that the original
11: DOOM sound code does not work without DMX. As
12: DMX is not publicly available, the original DOOM
13: sound support is removed.
14:
15: Win32 was not supported in the source dump I got.
16: I have no knowledge how the WinDOOM port did the
17: sound handling. A Win32 port should probaly rely on
18: DirectSound. So far, the Win32 glDOOM port Jim Dose
19: is working on has no sound support.
20:
21: In consequence, the only target with a working sound
22: code is UNIX, which I could only verify with Linux
23: on Intel586.
24:
25: 2) Linux sound
26:
27: DOOM for Linux used a separate process, sndserver.
28:
29: Quoting Dave Taylor:
30:
31: "Sound drivers should be an asychronous model, either
32: a seperate thread or a seperate process. This is
33: because sound should always be fed to the card without
34: interruption or else you get pops and with low latency
35: or else you get angry players.
36:
37: Now it turns out that this kind of code isn't too fun
38: to write. In the days of Linux Doom, threads were not a
39: happnin thing in Linux. In fact, they still largely
40: aren't. You can use them these days if you have gnu's
41: libc installed, but you still can't debug them because
42: gdb doesn't support them properly yet. I believe the
43: original seperate process had a bad latency delay
44: because of the time it took for commands to be flushed
45: through the pipe used to communicate with the seperate
46: process. I should have looked into this more thoroughly.
47:
48: In Quake, I discovered that I could feed multiple
49: acknowledgements to a SoundBlaster or compatible without
50: any side-effects such as pops or other malfunctions.
51: This discovery led me to switch to a completely synchronous
52: model, much much easier to debug and understand, so I
53: think this was fairly intelligent. Although we had to
54: populate the game with calls in the right places to keep
55: the sound buffers fed, and although it wasn't gauranteed to
56: be always fed, well over 99% of the time, it was fed, and
57: your the latency was never worse than the frequency of your
58: refills (several times per frame) plus a small lead time
59: (40th of a second?)."
60:
61: The separate sndserver code base introduced some redundancy
62: (WAD access for sound lumps) for each UNIX target (Sun, SGI,
63: Linux) and more differences between DOS and UNIX version.
64: However, I kept the IPC based parts in the source, and
65: separated the sndserver target in another directory to avoid
66: further redundancy. There seem to be a few bug-like things
67: going on in the sndserver that do not receive penalty as
68: the program has to do only a simple task. One example would
69: be a libc realloc mixed with zone memory allocation.
70:
71: Ungraceful and untimely demise of Linuxdoom (core instead
72: of I_Error) will leave idle sndserver processes in your
73: system, blocking /dev/bsp. Kill them manually.
74:
75: I put the non-redundant parts of the sndserver program
76: into the i_sound module of doom, and with the SND_SERV
77: compiler switch you can choose to use the internal sound
78: support. However, there is a problem with e.g. the
79: double shotgun and the plasma gun - walk up to a wall,
80: face it straight, and fire. The sound output is crappy.
81: This vanishes with decreasing screen size. A similar
82: problem occurs with trimer driven asynchronous output
83: enabled by SNDINTR.
84:
85: I agree with Dave that threads would be preferable.
86: With respect to Linux ports of John Carmack's next
87: Trinity engine, this one will rely on Win32
88: multithreading e.g. for input sampling. So the Linux
89: community will have to sort out threads anyway :-).
90:
91: To improve the current sound server, other means of
92: IPC should take care of the latency. The mixing
93: buffer/command buffer as shared memory comes to mind.
94:
95:
96:
97: 3) Music support
98:
99: There is, and was, no music support in Linuxdoom. Fine with
100: me - I wouldn't give a bat's tail feathers for DOOM music.
101: Your mileage may vary. There are a few leftovers of the DOS
102: music support also interfacing DMX, so there is a place
103: to start. However, in the age of CDROM based music, I
104: recommend getting e.g. Workman to cooperate with DOOM
105: (currently, DOOM accessing the soundcard SpekerOut
106: interferes with Workman controlling the CD drives
107: SpeakerOut), so musci could be chosen and run completely
108: independend of the game. You could try Linuxdoom with
109: Q2 music that way.
110:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.