Return to readme.sound CVS log

Up to [DOOM] / doom

Annotation of doom/readme.sound, revision 1.1

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.