Debugging Your Speakers - Revision history

Plasticman: Changed "s_drawSpeakers" (which does not exist) to "s_drawSounds" (which was meant in the first place).

2013-02-07T06:52:34Z

Changed "s_drawSpeakers" (which does not exist) to "s_drawSounds" (which was meant in the first place).

← Older revision		Revision as of 06:52, 7 February 2013
Line 8:		Line 8:
	Should be self-explanatory that you can't judge your map's sound design via the tiny speakers in your notebook.		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_drawSpeakers~~ ==		== Make Speakers visible with s_drawSounds ==

	===The Basics===		===The Basics===

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

	<code>~~s_drawSpeakers~~ 1</code>		<code>s_drawSounds 1</code>

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

	<code>~~s_drawSpeakers~~ 2</code>		<code>s_drawSounds 2</code>

	shows all of them in the map.		shows all of them in the map.
Line 66:		Line 66:
	===Propagation through multiple Portals===		===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 ~~drawSpeakers~~ tool to show an appropriate bended line, but it doesn't.		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:		A basic setup with multiple portals, one speaker and one "Listener" (the player), may look like this:
Line 76:		Line 76:
	[[Image:DrawSounds_Portals_2.png]]		[[Image:DrawSounds_Portals_2.png]]

	The lines drawn by ~~drawSpeakers~~ only show you		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 sound is originating from while you hear it (that is the active portal nearest to the actual source speaker).
	* where the originating speaker is.		* where the originating speaker is.

Plasticman at 06:00, 6 February 2013

2013-02-06T06:00:37Z

← Older revision		Revision as of 06:00, 6 February 2013
Line 103:		Line 103:
	A more elegant way to trace volume issues would be doom's built-in volume meter. It can be enabled via		A more elegant way to trace volume issues would be doom's built-in volume meter. It can be enabled via

	<code>~~s_showLevelMeters~~ 1</code>		<code>s_showLevelMeter 1</code>

	but seems to be broken in TDM right now.		but seems to be broken in TDM right now.

Plasticman at 05:54, 6 February 2013

2013-02-06T05:54:09Z

← Older revision		Revision as of 05:54, 6 February 2013
Line 9:		Line 9:

	== Make Speakers visible with s_drawSpeakers ==		== Make Speakers visible with s_drawSpeakers ==

			===The Basics===

	Sound emitting entities can be made visible using the ''s_drawSpeakers'' command in the console:		Sound emitting entities can be made visible using the ''s_drawSpeakers'' command in the console:
Line 53:		Line 55:
	[[Image:Drawsounds_shot03.png]]		[[Image:Drawsounds_shot03.png]]

	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).<br>		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).<br>
	You can not see the difference between ''O'' and ''D'' in this shot due to rounding.<br>		You can not see the difference between ''O'' and ''D'' in this shot due to rounding.<br>

	Closing the door will add a fixed "length" to the relative distance (in TDM that's ca. 12 of ~~doom~~'s crude sound units):		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.''):

	[[Image:Drawsounds_shot02.png]]		[[Image:Drawsounds_shot02.png]]

	''D'' is still 2 (line of sight didn't change), ''O'' is in deed something near 14, but gets capped equivalent to maxDistance.		''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 drawSpeakers 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:

			[[Image:DrawSounds_Portals_1.png]]

			Sound propagation and it's visualisation differ:

			[[Image:DrawSounds_Portals_2.png]]

			The lines drawn by drawSpeakers 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. :)		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~~:<br>~~		===Issues===
	* If you turn occlusion off (globally or just on certain entities) it has no effect on what drawsounds shows you.		* 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.		* 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.		* Sound entities change their color. That's propably distance related, but the exact meaning of the colors is a mystery to me.

Plasticman at 17:14, 28 November 2010

2010-11-28T17:14:40Z

← Older revision		Revision as of 17:14, 28 November 2010
Line 60:		Line 60:
	[[Image:Drawsounds_shot02.png]]		[[Image:Drawsounds_shot02.png]]

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

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

Plasticman at 16:56, 28 November 2010

2010-11-28T16:56:32Z

← Older revision		Revision as of 16:56, 28 November 2010
Line 49:		Line 49:
	<code>r_showportals 1</code>		<code>r_showportals 1</code>

	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.		will show these red lines often point to a visportal. This illustrates how sound propagation takes map geometry into account ([[Setting Up Speakers#no_occlusion/ s_occlusion\|occlusion]]). The sound does not travel the shortest distance (line of sight), but takes a more realistic route around the corner.

	[[Image:Drawsounds_shot03.png]]		[[Image:Drawsounds_shot03.png]]
Line 74:		Line 74:
	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.		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.		But for setting up your own sounds or fixing possible issues with "broken" assets, you can use [[Setting Up Speakers#volume/ s_volume\|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:		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:
Line 93:		Line 93:

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

			[[Category:Sound]]
			[[Category:Editing]]

Plasticman: New page: 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 b...

2010-11-28T16:43:54Z

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

New page

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.<br>
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_drawSpeakers ==

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

<code>s_drawSpeakers 1</code>

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

<code>s_drawSpeakers 2</code>

shows all of them in the map.

A typical speaker will look like this:

[[Image:Drawsounds_shot01.png]]

The information inside the cube has the form

<pre>

<name> (O/D min/max)

n

</pre>

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:

<code>r_showportals 1</code>

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.

[[Image:Drawsounds_shot03.png]]

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).<br>
You can not see the difference between ''O'' and ''D'' in this shot due to rounding.<br>

Closing the door will add a fixed "length" to the relative distance (in TDM that's ca. 12 of doom's crude sound units):

[[Image:Drawsounds_shot02.png]]

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

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:<br>
* 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.
* 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:

<code>s_clipvolumes 0</code>

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

<code>s_showLevelMeters 1</code>

but seems to be broken in TDM right now.

== Other tools ==

<code>s_useocclusion 0</code>: 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'').

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