home *** CD-ROM | disk | FTP | other *** search
/ ST-Computer Leser-CD 2000 January / LCD_01_2000.iso / games / doom / pmdoom / doc / sound < prev    next >
Encoding:
Text File  |  1999-12-17  |  4.4 KB  |  111 lines
  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.  
  111.