Debugging Your Speakers

This is some sort of a follow-up, please read first Setting Up Speakers.

Don't forget your ears

There are ways to visualize what's going on with the audio in game, and it can be tempting to rely too much on that. But what finally counts is what can be heard by the player.
So just like it is clear that you check your map's visuals with your eyes, it should be clear that you check the audio with your ears.

Should be self-explanatory that you can't judge your map's sound design via the tiny speakers in your notebook.

Make Speakers visible with s_drawSounds

The Basics

Sound emitting entities can be made visible using the s_drawSounds command in the console:

s_drawSounds 1

will show speakers that are in reach to the player, the ones, that can be heard at the moment.

s_drawSounds 2

shows all of them in the map.

A typical speaker will look like this:

The information inside the cube has the form

<name> (O/D min/max)
          
          n

and means:

<name>: the name of the shader or sound

O: relative distance to the player (with occlusion)

D: real distance to the player

min: the minDistance

max: the maxDistance

n: the speaker's number

When you look at more remote speakers, like for example in the next room, you may notice there are red lines, vectoring away from the entity.

It is easier to see what is going on with portals visible:

r_showportals 1

will show these red lines often point to a visportal. This illustrates how sound propagation takes map geometry into account (occlusion). The sound does not travel the shortest distance (line of sight), but takes a more realistic route around the corner.

The speaker entitiy is behind the wall, the red line shows the way through an open portal, a door in this case. The volume at the player position depends on this relative distance (except when occlusion is explicitly disabled, i.e. only for debugging).
You can not see the difference between O and D in this shot due to rounding.

Closing the door will add a fixed "length" to the relative distance (in TDM that's ca. 12 of Doom's crude sound units -- edit: source code hints they were originally meant to resemble Meters. Since TDM geos big compared to Doom, they turn out to be very short Meters.):

D is still 2 (line of sight didn't change), O is in deed something near 14, but gets capped equivalent to maxDistance.

Propagation through multiple Portals

When a sound is propagated through more than one portal it has to be bended around many corners. You would expect the drawSounds tool to show an appropriate bended line, but it doesn't.

A basic setup with multiple portals, one speaker and one "Listener" (the player), may look like this:

Sound propagation and it's visualisation differ:

The lines drawn by drawSounds only show you

• where the sound is originating from while you hear it (that is the active portal nearest to the actual source speaker).
• where the originating speaker is.

The ralative dastance, the amount of occlusion, is not affected by this visualisation. The yellow line shows the distance that really is taken into account by the sound engine. The value of O, the relative distance shown on the drawn Speaker itself, is correct and differs from the length of the red line.

Together drawsounds and showportals make a nice toolset to optimize both your speaker setups and your placement of visportals (now with sound propagation in mind). You can add the spyglass to that toolset, remote speakers are sometimes hard to read.  :)

Issues

• If you turn occlusion off (globally or just on certain entities) it has no effect on what drawsounds shows you.
• Sometimes the red lines can go to weird places. Esp. with s_drawSounds 2 all inactive entitites seem to point at a common origin. -- edit: looks like they point to the last known position played from. When propagated through a portal it points there. At map start sounds are not played yet, so they point to 0,0,0.
• Sound entities change their color. That's propably distance related, but the exact meaning of the colors is a mystery to me.

Getting the Volume right

The right value for the volume setting of a sound should be correctly set in it's shader. So in a perfect world it shouldn't need any fixing by mappers.

But for setting up your own sounds or fixing possible issues with "broken" assets, you can use the s_volume property.

Since all sounds that don't have the unclamped keyword in their shader get capped by the sound engine before any real clipping occurs, it is not easy to spot when you're over the limit. There's a cure, that at least should work for normalized sounds:

s_clipvolumes 0

will disable the engine's clipping protection. As a result affected sounds will cause hardware clipping -- you can't miss that.

A more elegant way to trace volume issues would be doom's built-in volume meter. It can be enabled via

s_showLevelMeter 1

but seems to be broken in TDM right now.

Other tools

s_useocclusion 0: Will turn off occlusion on a global level. Sound propagation will always be line of sight. It is not visualized by drawsounds. Can be useful for comparison, esp. when bound to a key (bind n toggle s_useOcclusion).

com_showdecoders 1: Will draw a few lines on your screen, showing the sounds currently playing.