Volume Issues

The following is qouted from the forum.

Compare "proper" articles in the making: Setting Up Speakers and Debugging Your Speakers

by Plasticman

I did some reading on iddevnet and checked a few things in game.

I think Orb is right: the volume gets capped on both channels so the sound virtually moves to the center. I consider this a bug in doom, though it only appears once the assets are produced "wrong". Still it should not break the left vs. right balance.

The mechanism can be controlled globally via the s_clipVolumes cvar (works instantly without restarting anything) and locally (overriding the cvar) via the unclamped keyword in the soundshader (always wondered what this bes). Any sound that comes with this declaration will not be clipped in doom no matter what the cvar is -- this means it will be clipped by the hardware if it is too loud. :D

So, the purpose of dooms clipping is to prevent overdriving your audio hardware, some sort of "fuse" that normally should not get triggered by the assets.

Although volume refers to a decibel value (and thus defaults to 0) there seems to be a little headroom. There are roundabout 3400 shader declarations in vanilla doom that use the volume keyword. Positive values distribute like this:

volume / number of shader declarations

> 0 : 1441
> 5 : 430
> 10 : 83
> 15 : 54
> 20 : 8

The maximum is 30 (used 2 times). I guess the few with real high values are only rarely used in situations where it doesn't matter, like cutscenes etc.; some of the others are important for gameplay and this is what I think the headroom is meant for, so you can "lift" some of the more important sounds over the usual ambience buzz.

How much space there is I don't know. But I assume it does not work like a limiter in an audio app -- they wouldn't waste any CPU resources for audio processing when those are needed for calculating shadow volumes. So it likely does not matter how much dB your sound really is, the audio data gets treated like 0 dB plus what the shader says.

If I am right with that assumption the Pro needs some dynamic processing besides fixing in the shader. Here is a comparison shot:

s_drawsounds

There is a cvar to make sounds visible: s_drawsounds. "0" disables it, "1" shows sounds that can be heard at the moment, "2" seems to draw all sounds. This will show a box where the speaker is and label it something like this:

rock_door_loop (3/3 2/26)
9
That translates to
<shader> (a/b c/d)
e

Where a is the calculated distance (through doors and portals), b is the real distance (line of sight), c is minDistance, d maxDistance and e seems to be the number of the speaker.

This little tool showed me there are quite a few sounds in game that seem to work with a minDistance of 0. But when I set up a speaker in Radiant with s_minDistance 0 it shows up in game with minDistance 20, independent of the other factors (vol., maxdist.).

My map file looks fine in a text editor, so it must be (again) doom's fault: minDistance 0 works, s_minDistance 0 gets "converted" to 20.