Volume Issues - Revision history

Petike: adding missing categories

2018-10-20T09:57:34Z

adding missing categories

← Older revision		Revision as of 09:57, 20 October 2018
Line 42:		Line 42:

	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.		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.

			[[Category:Sound]]
			[[Category:Troubleshooting]]

Plasticman: links added to "proper" articles

2010-11-25T02:50:30Z

links added to "proper" articles

← Older revision		Revision as of 02:50, 25 November 2010
Line 1:		Line 1:
			::The following is qouted from the forum.
			::Compare "proper" articles in the making: [[Setting Up Speakers]] and [[Debugging Your Speakers]]

	''by Plasticman''		''by Plasticman''

Springheel at 18:15, 23 November 2010

2010-11-23T18:15:46Z

← Older revision		Revision as of 18:15, 23 November 2010
Line 28:		Line 28:
	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:		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)		rock_door_loop (3/3 2/26)
	9		9
	That translates to		That translates to
	<shader> (a/b c/d)		<shader> (a/b c/d)
	e		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.		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.

Springheel at 18:15, 23 November 2010

2010-11-23T18:15:06Z

← Older revision		Revision as of 18:15, 23 November 2010
Line 12:		Line 12:

	volume / number of shader declarations		volume / number of shader declarations
	> 0 : 1441
	> 5 : 430		> 0 : 1441
	> 10 : 83		> 5 : 430
	> 15 : 54		> 10 : 83
	> 20 : 8		> 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.		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.
Line 24:		Line 25:
	If I am right with that assumption the Pro needs some dynamic processing besides fixing in the shader. Here is a comparison shot:		If I am right with that assumption the Pro needs some dynamic processing besides fixing in the shader. Here is a comparison shot:

	~~Attached Image~~		== s_drawsounds ==


	~~As you can see someone had a reason to give the Pro a raise...~~
	;)

	~~View PostSpringheel, on 22 November 2010 - 02:55 PM, said:~~
	~~I'm a bit surprised no one has mentioned any problems with them.~~

	~~People just don't SEE those things...~~

	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:		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:

Springheel: New page: ''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 cente...

2010-11-23T18:13:41Z

New page: ''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 cente...

New page

''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:

Attached Image

As you can see someone had a reason to give the Pro a raise...
;)

View PostSpringheel, on 22 November 2010 - 02:55 PM, said:
I'm a bit surprised no one has mentioned any problems with them.

People just don't SEE those things...

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.