How exactly did the linuxdoom sndserver used to work?

[HotCoffee]

I'm trying to port the audio of linuxdoom to SDL2 but I don't understand how the sounds are played.

There is the function "I_StartSound()" which I'm supposed to implement:
 

int

I_StartSound

( int id,

int vol,

int sep,

int pitch,

int priority )

But where is the actual sound in the parameters? There is this "id" but I don't know what to do with it.

Also I don't fully understand how Doom and the SoundServer used to communicate.

In the code there is this line:

fprintf(sndserver, "p%2.2x%2.2x%2.2x%2.2x\n", id, pitch, vol, sep);

Which looks like it's writing the parameters to the sound server executable, but it doesn't make any sense to write to a binary file.

Also why is it called "Sound Server" when it's actually in the same machine running Doom?

Why couldn't the sound server be compiled with Doom and not to be a different executable?

[Dark Pulse]

The reason is that the DOS version of Doom used DMX, which was a commercial sound library not developed by them. For legal reasons, this couldn't be incorporated into the opensourced code, so for Linux, a separate sound server was set up to do the work on sound instead.

[andrewj]

The "id" parameter is a sound number, like sfx_pistol or sfx_doropn, and the lump names are defined in S_sfx array.  See sounds.c and sounds.h code files.

 

The soundserver was a program which linuxdoom spawned (i.e. ran it), and they communicated via pipes.  I think it had wad loading code, so it could load sounds from a wad and play them.

[wesleyjohnson]

DoomLegacy is related to linuxdoom.

 

Probably easiest to just use what you need from DoomLegacy.

Whatever method you want to use, DoomLegacy probably has the code for it already.

There are log files in the source code package (logs/WDJlog), and I have individual patches (which can also be extracted from the repository).

 

Running the sound server as a separate task makes the sound cleaner because the system will interrupt to service the sound server.

The operating system ensures that the sound server is run often enough, and when events happen to it.

It does not depend at all on what Doom is doing, or how long it is going to take to finish it.

Doom can even go and read disk files (notoriously slow and a music killer).

 

When the sound is directly played by Doom, the sound is at the mercy of how fast Doom can finish drawing, and can it get back

and refill the sound buffer before it runs dry.  If the buffers run dry it causes noise in the sound and music, and the drivers declare an under-run

condition, and that error then must be cleared.

 

If the sound buffers are made too large, then there is a noticeable delay when trying to stop a sound, or play different music.

Large sound buffers cause sound latency.  The sound seems to always be reacting slowly, leading to sound artifacts.

A gun shot will not play when the gun is fired, but will be delayed a bit because all the stuff already in the mixed sound buffer must be played before

the driver even gets to the newly added gun shot.

 

Mixing all the current real-time sounds together for the next period is what the sound player must periodically do, and must do it reliably without fail.

Make that period too short and Doom will fail to get back in time to add more, and the buffer will run dry (very audible).

Make the period too long, and new sounds will be delayed for the duration of that period.

 

---- SDL sound

For SDL and SDL2 sound: see doomlegacy/src/SDL.

The SDL and SDL2 sound do not use the Doom sound server code, that is taken care of by SDL (which I think launches its own sound servers).

There is a option to compile for SDL, or SDL2, so the SDL2 compatibility has also been taken care of.

 

The SDL2 port currently will only play MIDI using  FluidSynth because SDL2 includes a copy of FluidSynth in the SDL2 library, always uses it when it can, and provides no way to force something else to be used.

FluidSynth sounds weird compared to TiMidity, but that may be due to the instrument package it uses.

 

I you are going to use SDL2, you do not need the Linux sound servers.

In the DoomLegacy source code, there is code for handling SDL and SDL2 sound.

It has DoomLegacy mixing the sound effects, so that latency is low  ( see I_UpdateSound_sdl ).

You only need the sound functions from the src/sdl/i_sound.c files, which will mix the sounds and send the buffer to SDL (SDL2).

 

Music uses the SDL mixer, which can handle various music formats (including MP3), and does not need much servicing.

The output of the SDL music mixer is fed into the DoomLegacy sound mixer automatically.

That is, the SDL music mixer will have already put the current music mixed data into the mixer buffer that the sound effects mixer is using.

 

 

---- Linux sound

For Linux sound: see  doomlegacy/src/linux_x.

Linux sound only applies if you are compiling for the X-windows target.

The DoomLegacy Linux sound server was recently updated to fix a whole host of bugs.

There is an option to compile a sound server, or it can play sound in-game.  The sound server plays better, but cannot tell the main program when it is done playing.

The Linux sound and music provide for selection of the Linux device used to play sound and music.

 

There are a separate sound server and music server, each which connects to DoomLegacy by a pipe.

 

The id parameter is a sound id number.

DoomLegacy uses a function, I_GetSfx, to load the sound lump and send it to the sound server through the pipe.

I believe the original code would have the sound server parse the wad file itself and load the sound lumps.

 

DoomLegacy Linux sound adopted the Michael Heasley doom music player (1995-1996).

The current DoomLegacy is still sending the wad filename to the music server, and the music lumpnum, and the song name.

The music server must get the music lump itself.

The music server uses readwad.c (from the Michael Heasley doom music player) to read the wad, and extract the music lump itself.

 

---- Other

The Linux port code also has an option for Allegro, but it has not been tested in ages.

The FMOD option just gives you messages that FMOD is not yet supported.

 

 

Edited September 15, 2022 by wesleyjohnson

[nukeykt]

You probably can check gamesrc-ver-recreation's doom repository to see how things worked in original DOS version(s):
https://bitbucket.org/gamesrc-ver-recreation/doom