Jump to content
The Dark Mod Forums

Volume Issues


plasticman

Recommended Posts

Okay, I may have found something.

 

When minDistance is set to 0 it sounds like it falls back to a value that is somewhat maxDistance - x. For a vast speaker setup this results in the unrealistic falloff behavior you described.

 

Inside the boundaries of maxDistance I can locate sounds when volume (or s_volume in DR) is 0 or less than 0. Positive values gradually make location impossible. This starts at the origin, raising the value expands the affected area. It seems to override minDistance, the falloff area gets smaller at the same time and there is no gain in volume from a certain point on.

 

I can reproduce this in Linux and Windows. The attached demo map illustrates the problem.

 

If it's not only me, this means:

 

  • Volume settings in sound shaders are critical. Unless your sound is omnidirectional avoid positive values for volume (I have a feeling 10 should be the maximum for really loud machinery, earthquakes, thunder, etc).
  • Mappers should be aware of this, because they can override the shader's setting via the s_volume spawnarg.
  • Some shaders need fixing: the "pro"-vocal set defaults to volume 20. It is almost impossible to say where the voice comes from. :(

I did not check what all these s_@x$%! cvars do. If there is a thread/wiki-entry/whatever somewhere buried that can enlighten me about all of these things...

sndt.map.txt

Link to comment
Share on other sites

  • Replies 52
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

When minDistance is set to 0 it sounds like it falls back to a value that is somewhat maxDistance - x. For a vast speaker setup this results in the unrealistic falloff behavior you described.

 

But it is more realistic for regular sounds, correct? We changed our vocals and footsteps to a minDistance of 0 (or was it 1?) because inside the minDistance there is no falloff, so you couldn't tell if an AI was walking towards you or away, for example.

 

Inside the boundaries of maxDistance I can locate sounds when volume (or s_volume in DR) is 0 or less than 0. Positive values gradually make location impossible. This starts at the origin, raising the value expands the affected area. It seems to override minDistance, the falloff area gets smaller at the same time and there is no gain in volume from a certain point on.

 

So you're saying that "volume" essentially works by raising the minDistance? That's definitely a problem.

Link to comment
Share on other sites

So you're saying that "volume" essentially works by raising the minDistance? That's definitely a problem.

 

 

If the volume is capped, then increasing the volume will also have the effect of expanding the minDistance; just like brightening a circular light falloff image will expand the white circle of maximum brightness in the centre.

 

 

Link to comment
Share on other sites

@Orb: like that. That's not what we want, right?

 

Is that sound stereo? I can't quite place it but compare how it sounds when the source is on the left versus the right. It's different.

It is mono. I set up four speakers in the map pointing to the same soundshader. The only difference is s_volume.

 

But it is more realistic for regular sounds, correct? We changed our vocals and footsteps to a minDistance of 0 (or was it 1?) because inside the minDistance there is no falloff, so you couldn't tell if an AI was walking towards you or away, for example.

Yes, real sounds do not have a something like minDistance. But we do not locate sounds (like footsteps) only by their volume. You can also tell if a guard in a hallway for example walks from the left to the right.

 

So you're saying that "volume" essentially works by raising the minDistance? That's definitely a problem.

Not by raising it, more by raising and breaking it. When I use minDistance 0 in my map I do not get the desired falloff, more something that sounds like minDistance 10 / maxDistance 26. With minDistance set to 1 I can clearly hear the falloff as it should be (one is close enaugh to zero in that case).

 

The slightly different issue I was trying to point out is: the falloff only works correct (between min. and maxdist.), when volume is <=0. A value like 20 will produce

  1. a falloff area that is much smaller like the space between minDistance and maxDistance. The louder the volume, the smaller the falloff area.
  2. a center area that is not bound to minDistance and at the same time breaks sound location in the stereo field. The sound becomes omnidirectional (like ambient music, only mono).

If for example a guards footstep sound was broken like this and you listen from inside a room how a guard passes by in the hallway, you would get the following: The guard is coming from the left side, you first get hit by a small falloff area where you can determine the sounds origin (left) and that he is coming closer (volume works, every step gets louder). Next you are in the rather big center area. You can not determine where the sound comes from, it is coming from everywhere. You do not hear wether the guard is approaching or leaving (volume is capped). Finally comes the the other end of the falloff, where it works as intended.

Edited by plasticman
Link to comment
Share on other sites

@Orb: like that. That's not what we want, right?

 

No, the result is not desirable, but there is probably no way around it if the Doom 3 sound engine has an internal volume cap.

 

Not by raising it, more by raising and breaking it. When I use minDistance 0 in my map I do not get the desired falloff, more something that sounds like minDistance 10 / maxDistance 26. With minDistance set to 1 I can clearly hear the falloff as it should be (one is close enaugh to zero in that case).

 

That's interesting, so minDistance 0 is invalid but minDistance 1 works. This should be easy enough to workaround, as you say 1 is pretty close to 0.

 

a center area that is not bound to minDistance and at the same time breaks sound location in the stereo field. The sound becomes omnidirectional (like ambient music, only mono)

 

That almost sounds like the volume increase is being applied after the stereo pan, so that the louder channel is capped but the quieter channel is increased in volume, pushing the sound towards the centre.

 

So it seems like the conclusion is that positive volume increases should not be used, and that minDistances should be 1 instead of 0.

Link to comment
Share on other sites

So it seems like the conclusion is that positive volume increases should not be used, and that minDistances should be 1 instead of 0.

 

Our footsteps and vocals already use a minDistance of 1, so that's good.

 

I'm a bit confused though...given the information presented here, shouldn't the pro vocals(with a volume of 20) be really messed up? I'm a bit surprised no one has mentioned any problems with them.

Link to comment
Share on other sites

I just did a quick and dirty test...put myself in the middle of a bunch of proguards who where searching, and then closed my eyes and spun around randomly to see if I could identify which speaker the voice was coming out of. I couldn't hear any difference at all as I spun around...it did indeed sound like the voice was omnidirectional. The footsteps were a little easier to distinguish (though not great).

 

I'll have to test with some vocals that don't use a positive volume.

Link to comment
Share on other sites

Thanks for the comfirmation. We can rule out for sure it happens only on my machine methinks.

 

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:

 

post-2180-129049145955_thumb.jpg

 

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

;)

 

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.

 

Hope I don't sound like ranting, just wanted to write things down in case I get hit by a train tomorrow...

 

:)

Link to comment
Share on other sites

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

 

The code we are seeing is:

 

   refSound->parms.minDistance = args->GetFloat( "s_mindistance" );

 

E.g. there is no default, so if you set s_mindistance to "0", it stays that way. If there is indeed a "0 => 20" logic, it must be in the closed part of the source. All we could do is enforcing it to be f.i. 0.1, by changing this to:

 

   refSound->parms.minDistance = args->GetFloat( "s_mindistance", "0.1" );

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

I'm not a coder, but what I gather is: it's not broken in the SDK, but enforcing all s_minDistances to a fixed value is possible.

 

While it is not a correct model for sfx, we still want to keep s_minDistance customizable (for ambient sounds). Esp. since it only occurs when explicitly set by the mapper. :)

Link to comment
Share on other sites

Thanks for that plasticman, that's a lot of very useful information you have discovered. I knew about s_drawSounds, but I had no idea what the numbers meant.

 

It's good that we now know how volume is handled; you explanation is certainly consistent with my observations (i.e. that positive volume increases don't seem to work, because the unclamped keyword is not also set). And you are correct that any problems we have are due to the assets not the SDK, and should ideally be fixed by modifying volumes or processing the audio if necessary.

Link to comment
Share on other sites

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

 

Do we have the pro wav files to work from?

Link to comment
Share on other sites

Just for the record: I noticed when applying the "shakes" parameter to the running footstep sounds, the volume value from 1 to 100 had an effect on the amount of shaking.

 

Great job plasticman.

 

 

Audio question: If your volume on your speakers were low, like say 30%, would clipping sounds hurt your speakers?

 

edit: "on the about"?...

Link to comment
Share on other sites

Audio question: If your volume on your speakers were low, like say 30%, would clipping sounds hurt your speakers?

 

Clipping doesn't hurt your speakers (unless you are listening at extremely high volumes, in which case any normal sound could cause similar damage), it just sounds terrible.

Link to comment
Share on other sites

Link to comment
Share on other sites

A quick check shows that most of our vocals have a positive volume--generally 8.

 

 

If I load the original pro .wavs and run them through a normalize effect in Audacity, is that going to make them louder without any loss of quality?

Link to comment
Share on other sites

If I load the original pro .wavs and run them through a normalize effect in Audacity, is that going to make them louder without any loss of quality?

 

 

There won't be loss of quality, but it might not give much volume increase depending on how they were recorded. Some compression/limiting might also be required (http://en.wikipedia.org/wiki/Dynamic_range_compression)

 

 

I think we need to set out some guidelines for the expected volume levels of gameplay elements, so as to avoid continuously tweaking one thing only to discover that they no longer match the volume of something else. Then all of the vocals could be processed as necessary to fit into this framework.

Link to comment
Share on other sites

I think we need to set out some guidelines for the expected volume levels of gameplay elements, so as to avoid continuously tweaking one thing only to discover that they no longer match the volume of something else. Then all of the vocals could be processed as necessary to fit into this framework.

 

Yes, that's probably true. I certainly don't have the knowledge to do that.

 

In the meantime, should I try boosting the pro vocals?

Link to comment
Share on other sites

In the meantime, should I try boosting the pro vocals?

 

I just checked a couple of the source WAVs, and yes they are indeed very low (the two I tested were peaking at -10 and -11 dB). In this case normalising them is definitely needed.

 

It is probably something I can do much more easily by automated scripting in Linux, but by all means feel free to have a go with Audacity as well if you like.

Link to comment
Share on other sites

It's easy enough to do in Audacity, if that's all that's needed. I've already converted them all, and I'll run a few tests to compare the volume to our existing vocals.

Link to comment
Share on other sites

[not fast enough]

For the comparison shot above I copied all the pro vocals into one file. The peaks go to 0 dB, so overall the set is normalized. The problem comes with the camparatevely high dynamic range, i.e. some utterances are very silent, near the -20 dB mark.

 

For a temporary fix, boosting in Audacity should do -- iirc you can do batch processing from the menu, what will save you a lot of mousework. :)

[/not fast enough]

 

In the meantime I found the culprit in my s_mindistance 0 issue: It's as easy as that, when doom sees the property is set to 0 in the map file it treats it as if it wasn't set at all. As a consequence it falls back to what the shader says. If the shader has no info as well it defaults to minDistance 1/maxDistance 10. (Yes, I tried what happens when you set maxdistance to 0.)

 

What happened to me was the rock_door_loop shader in TDM. It defines minDistance 20. My mapper input s_mindistance 0 made it fall back to that ridiculous high value, that only makes sense as a typo in the shader...

...without it I wouldn't have noticed the issue.

 

I'll see to make the info available in the wiki -- just registered. :)

Edited by plasticman
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
    • Ansome

      Well then, it's been about a week since I released my first FM and I must say that I was very pleasantly surprised by its reception. I had expected half as much interest in my short little FM as I received and even less when it came to positive feedback, but I am glad that the aspects of my mission that I put the most heart into were often the most appreciated. It was also delightful to read plenty of honest criticism and helpful feedback, as I've already been given plenty of useful pointers on improving my brushwork, level design, and gameplay difficulty.
      I've gotten back into the groove of chipping away at my reading and game list, as well as the endless FM catalogue here, but I may very well try my hand at the 15th anniversary contest should it materialize. That is assuming my eyes are ready for a few more months of Dark Radiant's bright interface while burning the midnight oil, of course!
      · 4 replies
×
×
  • Create New...