Smirftsch wrote on Jul 9^th, 2017 at 6:03am:

The latest one - 2.4.7. By crackling i mean the static noises coming from the speakers with 2-6 sec interval.

There are some new options you may want to adjust:

ViewportVolumeIntensity
which scales the volume for all sounds relative to the player

and when using UseSpeechVolume
SpeechVolume
which affects the "speech" - or well grunts or whatever most creatures do.

other than that there is
OldReverbIntensity
ReverbIntensity

which are for the reverb (echo) effects, however for standard maps there is usually only OldReverbIntensity in use.

I noticed music always needs a boost to be equal, so you could try
MusicAmplify=2
if that's the case for you too.

A lot of these things depends also on speaker setup (such as stereo or f.e. surround 5.1), so it's a bit hard to find sane default values.

Kain wrote on Nov 7^th, 2017 at 10:12pm:

I just checked how ALAudio works in 227j_38 (I don't use ALAudio other than for rare tests), and I could reproduce that issue.

The disbalance between different sounds is caused by changing the volume settings from the default values. When I set sound volume to a low value, PlaySound does not cap high volume values (above 1) by 1 (while normally values above 1 should be capped so), hence some sounds are played at abnormally high volume.

So, in order to bypass the given bug, you can try to set

SoundVolume=192
UseSpeechVolume=False

and adjust the volume by external means (e.g. using the Windows volume control).

Modifying ViewportVolumeIntensity unlikely makes any sense (unless you're going to do some specific sound tests), so better keep it equal to 1.000000 (which is the default).

The so called speech volume control in >99.99% cases affects everything but real speech (someone's claims that death screams, gasp sounds (when a player begins to breathe after drowning being underwater), jump sounds, cow shaking sounds, GasBag's farting, and so on can be considered as "speech" just make me laugh), so, again, unless you're going to do some specific tests, disabling this control is probably your best choice.

Also, in case if you don't like sound attenuation by obstacles (IMO, the way it works is nonsensical), set

bSoundAttenuate=False

I don't know if ALAudio supports mixing left/right sound channels for headphones (enabling UseHRTF makes sound quality too bad, so I don't consider it a viable option); if not, then you have 3 possibilities: mix channels using external means, choose other audio subsystem, or deal with messed up sound positioning (sometimes you'll have an impression that the source of a sound (be it an explosion, wind, waterfall, or something else) is located inside your left or right ear rather than several meters on the left or on the right of you).

Smirftsch wrote on Nov 9^th, 2017 at 3:32pm:

What subset of actors does play sounds as the "viewport", what does make that subset special, and what if some of such "special" actors do not play sounds as the "viewport"? F.e. when you fire 8Ball rockets, the fire sound (which is very loud) is played by the projectile and its volume is not controlled by the given config variable. If loud sounds produced nearby the player constitute a problem on such acoustic systems, I suspect that it could and should be resolved using other approach.

Quote:

"Voice Volume" would be much more close to the underlying functionality. This wouldn't change the fact that the set of affected voices is random though...

Quote:

If it was some special API function like PlaySpeechSound for playing real speech and users could expect a reasonable behavior from the corresponding volume control (which would be responsible for speech and _only_ for speech), I could use it in my version of Botpack (for announcer speech, taunts, tutorials) right now. But I do realize that the given volume control does not alter sound playback in a sensible manner, and it probably would be more convenient for users to modify special config variables in the mod than use the global voice volume control which would work well only when playing UT games under 227j client and mess up balance between sounds right after the user decides to play something else on the same client. What's the point to work on changing sound slots to support an inherently broken feature? Similar questions may arise when other mod writers would make their own decisions about this.

FYI, this is how SLOT_Talk is used in Botpack from UT v436:

Search "SLOT_Talk" (16 hits in 7 files)
  E:\Games\UT\UT_436\Botpack\Classes\Bot.uc (5 hits)
	Line 660: 	PlaySound(Deaths[rnd], SLOT_Talk, 16);
	Line 713: 		PlaySound(GaspSound, SLOT_Talk, 2.0);
	Line 715: 		PlaySound(BreathAgain, SLOT_Talk, 2.0);
	Line 1915: 	PlaySound(JumpSound, SLOT_Talk, 1.0, true, 800, 1.0 );
	Line 6616: 		PlaySound(JumpSound, SLOT_Talk, 1.5, true, 1200, 1.0 );
  E:\Games\UT\UT_436\Botpack\Classes\HumanBotPlus.uc (1 hit)
	Line 287: 		PlaySound(LandGrunt, SLOT_Talk, FMin(4, 5 * impactVel),false,1600,FRand()*0.4+0.8);
  E:\Games\UT\UT_436\Botpack\Classes\PressureZone.uc (1 hit)
	Line 88: 				P.PlaySound( P.Die, SLOT_Talk );
  E:\Games\UT\UT_436\Botpack\Classes\ShockWave.uc (1 hit)
	Line 120: 	 PlaySound(Sound'Expl03', SLOT_Talk, 16.0);
  E:\Games\UT\UT_436\Botpack\Classes\SkaarjBot.uc (1 hit)
	Line 245: 				PlaySound(LandGrunt, SLOT_Talk, FMin(5, 5 * impactVel),false,1200,FRand()*0.4+0.8);
  E:\Games\UT\UT_436\Botpack\Classes\TournamentPlayer.uc (6 hits)
	Line 114: 			PlayOwnedSound(JumpSound, SLOT_Talk, 1.5, true, 1200, 1.0 );
	Line 164: 	SoundPlayer.PlaySound(ASound, SLOT_Talk, 16.0, bInterrupt);
	Line 554: 	PlaySound(Deaths[rnd], SLOT_Talk, 16);
	Line 1008: 		PlaySound(GaspSound, SLOT_Talk, 2.0);
	Line 1010: 		PlaySound(BreathAgain, SLOT_Talk, 2.0);
	Line 1218: 		PlayOwnedSound(LandGrunt, SLOT_Talk, FMin(5, 5 * impactVel),false,1200,FRand()*0.4+0.8);
  E:\Games\UT\UT_436\Botpack\Classes\VacuumZone.uc (1 hit)
	Line 35: 			P.PlaySound( P.Die, SLOT_Talk ); 

The only use case related to speech is the last line in TournamentPlayer.ClientPlaySound:

//Play a sound client side (so only client will hear it
simulated function ClientPlaySound(sound ASound, optional bool bInterrupt, optional bool bVolumeControl )
{
	local actor SoundPlayer;
	local int Volume;

	if ( b3DSound )
	{
		if ( bVolumeControl && (AnnouncerVolume == 0) )
			Volume = 0;
		else
			Volume = 1;
	}
	else if ( bVolumeControl )
		Volume = AnnouncerVolume;
	else
		Volume = 4;

	LastPlaySound = Level.TimeSeconds;	// so voice messages won't overlap
	if ( ViewTarget != None )
		SoundPlayer = ViewTarget;
	else
		SoundPlayer = self;

	if ( Volume == 0 )
		return;
	SoundPlayer.PlaySound(ASound, SLOT_None, 16.0, bInterrupt);
	if ( Volume == 1 )
		return;
	SoundPlayer.PlaySound(ASound, SLOT_Interface, 16.0, bInterrupt);
	if ( Volume == 2 )
		return;
	SoundPlayer.PlaySound(ASound, SLOT_Misc, 16.0, bInterrupt);
	if ( Volume == 3 )
		return;
	SoundPlayer.PlaySound(ASound, SLOT_Talk, 16.0, bInterrupt);
} 

Quote:

I'll upload a video later.

Smirftsch wrote on Nov 10^th, 2017 at 7:16am:

The first question any developer should consider when implementing some feature is why that feature is worth implementing in the first place, what purpose it's supposed to serve. It is possible to implement a volume control for a random subset of sounds, but it's hard to explain what constitutes its practical usefulness besides speaking of contrived use cases that might be interesting for 1.5 people.

When it comes to speech, we can reasonably claim that it's a special subset of sounds, because it consists of phonemes which should be clearly distinguishable in order to let people understand the meaning of what is said. This specifics of speech sounds implies the potential usefulness of adjusting its volume to a value that would be sufficient for understanding the speech and not let it sound too loud (according to individual subjective perception) at the same time. However, in general, developers should initially pick an optimal volume of speech so that end users would want to adjust it as rare as possible (if users have to constantly move volume sliders back and forth, it's a sign that there is something wrong with the game).

When I consider myself as an end user, I expect the following functionality from a speech volume control: it should let me more clearly distinguish speech phonemes by increasing the volume or reduce the volume of such phonemes to a desirable level; any other kinds of sounds should not be affected. If I change speech volume and I get non-speech sounds affected as the result, I would consider such effect as unwanted and believe that it's a bug in the game (note that many potential players, who are not devs, would not even know what is SLOT_Talk and who should be blamed for unintuitive behavior of a volume control).

Quote:

If I do that, what implications would it have? As long as an end user plays as a TournamentPlayer with similar TournamentPlayers or with Botpack bots, the speech volume control would serve its purpose properly, but switching to something else would with nearly 100% probability break the balance between non-speech sounds, so the player would be forced to change the volume settings back and forth in order to achieve the desirable balance in either situation - this is simply not user-friendly.

Besides, porting Botpack alone is not interesting - this is the first step of making ports of such great campaigns as Operation Na Pali, Seven Bullets, and Project Xenome. Operation Na Pali and Seven Bullets have their own speech sounds, and in this case, a proper support of the speech volume control (following the current approach) would require noticeably more efforts, because I would have to subclass standard pawns in order to make them use "correct" slots. If some player or server admin decides to use additional mods (e.g. mutators that spawn custom pawns) which still "wrongly" use SLOT_Talk, then the balance between non-speech sounds can be broken again. Hence, in spite of the extra efforts (which would not be necessary if speech volume was managed in an appropriate way) I still would not be able to claim "my mod supports speech volume control which you can use without worrying about unwanted side effects on non-speech sounds".

Quote:

Some abstract similarities between speech, sounds produced by creatures, and non-speech sounds produced by players do not explain the practical value of having a special volume control for all such sounds together. Maybe if you try hard, you can find 10 similarities between speech and explosion sounds, but that won't explain the practical need in some imaginary volume control responsible for speech united with explosion sounds either. The consequence of your implementation choice is that those players who might want to adjust speech volume for the reasons explained above without affecting non-speech sounds simply won't find an appropriate volume control for their needs in the regular game menu. I personally find the current feature having a misleading name and practically useless, and since I can provide my own config variables that would affect only speech following the intuitive expectations and practical needs of users as close as possible, at this moment I don't see any non-contrived reasons to take special actions in order to support the broken built-in speech volume control (maybe until some users explicitly ask me to do so).

Masterkent wrote on Nov 10^th, 2017 at 1:53pm:


Thank you for this elaboration, I agree with you, this argument is convincing.
So, what way should we go here? I could imagine to add some new parameter such as SLOT_VOICE then and split it off this way by leaving only those things really as speech which are.
However, for voice I am not sure if I want to have a separate volume control for voice then, I tend not to have such a thing.

Smirftsch wrote on Nov 12^th, 2017 at 11:17am:

I need some time to think about it. I see difficulties with any approach that comes to mind. In particular, using a single slot may have some negative impact on backward compatibility (if we are ready to consider compatibility concerns valuable in this case). Sometimes it's necessary to get sound louder than we can currently achieve with a single call to PlaySound with the max possible volume. In such a case, we can call PlaySound several times to amplify the sound. Every call should either use a distinct slot or SLOT_None. An attempt to play a sound on the same slot other than SLOT_None of the same actor would result either in overriding the previously played sound or skipped playback (depending on bNoOverride).

We can invent some new means to amplify the sound played by a single call to PlaySound, but it won't work on older clients for obvious reasons.