Direct access of SoundClasses is no longer allowed

After updating our project to 4.13, we were hit with the warning:

'FAudioDevice::GetSoundClassPropertyMap': Direct access of SoundClasses is no longer allowed. Instead you should use the SoundMixClassOverride system Please update your code to the new API before upgrading to the next release, otherwise your project will no longer compile.

We are accessing sound classes directly by name and modifying their volume values currently. This is done so that players can change different volume settings.

TMap<class USoundClass*, FSoundClassProperties> SoundClasses = GEngine->GetMainAudioDevice()->GetSoundClassPropertyMap();

for (TMap<USoundClass*, FSoundClassProperties>::TIterator It(SoundClasses); It; ++It)
	USoundClass* SoundClass = It.Key();
	FSoundClassProperties SoundProperties = It.Value();
	if (SoundClass && SoundClass->GetName() == MASTER_SOUNDCLASS_NAME)
		if (MasterVolume != SoundProperties.Volume)
			SoundClass->Properties.Volume = MasterVolume;
	else if (SoundClass && SoundClass->GetName() == SFX_SOUNDCLASS_NAME)
		if (SfxVolume != SoundProperties.Volume)
			SoundClass->Properties.Volume = SfxVolume;

How exactly should we change this code in order to adapt to the new engine changes? I have had a hard time finding any examples of a scenario like this one.



The official answer is: “Use Mixer override to manage sound volume changes”.
That’s it. And frankly, I didn’t had time to dig into it but I didn’t understand how to implement it. I hope to have a clear example on this, but I can’t find anything on this, no sample, so explanation etc…

The sound settings are clear a dark zone.

I hope @Epic can help us with a simple example like:

Manage 2 sound class - Master & Weapon and how to change the sound volume as per User Settings.

From what I read, you can set Sound Class volume inside the mixer and you can override the mixer on a sound class. So, we might need to create a mixer with all the childs & master sound class volume and apply it at the Master Sound Class.
There is an option on the Mixer “Affect Childs”, so that’s confusing, as if all the childs sound class are coming to Master, do we need to tick this option…

all in all, I hope someone in the community or Epic can come with a example.

More, this should be inserted into a sample project or shooter game for reference.

@Duetoxplode I ran into this also. My Sound Options looked almost exactly like yours. The following is from memory, I’ll Edit later and add my code snippet.

My function is my GameInstance class.

I changed the C++ function to take a USoundClass* as an argument along with a float for volume, checked to make sure not null and then set the volume on the Sound Class. In the Header I added USoundClass* UPROPERTIES that are edit anywhere, such as Master, Music and FX.

Then in the Editor, in my Blueprint extending my GameInstance class I can set the USoundClass* from the content browser. I made sure all my sound clips have their SoundClass assigned correctly in their details panel.

Thanks ! This seems like a solid way of working around this issue.
My only concern is that it still seems as though we would be accessing sound classes directly, but without triggering the warning. I wonder how long that will last for.

No way to tell, but if they break it again can just opt to not upgrade engine version.

I tried using the mixers and it just didn’t seem appropriate for what I wanted, being the overall volume levels. The mixers reset at the beginning of each level and I couldn’t get them to work for overall volume levels from a menu in one level, then to be set everywhere for the whole game. I got no effect from them, zero. So, I did this workaround and set references to the SoundClass’s in the GameInstance Blueprint from the Editor.

If it is so dangerous to directly access a USoundClass the whole system should be re-coded so it no longer is, instead of making access private and telling people they aren’t using it right, even though good documentation wasn’t provided.

@mikepurvis So I ended up implementing something similar to what you had done.

Instead of storing the relevant SoundClasses on the GameInstance blueprint, I exposed our UGameUserSettings class to Blueprint. In that class I added UPROPERTIES for the relevant SoundClasses and set them via the blueprint. No more compiler warnings :slight_smile:

Thanks again for the help.

That’s a better solution, I like it.

The reason behind this is that the Audio is now in its own thread. This is why they made those things private.

I hope to see a real sample with the Mixer stuff because this is what they say we should do.

I saw in UT4 that they need to work on this (they put a comment on it) but for the time, they put some macro to avoid warning and so on!

For reference:

Hey guys,

Have you been able to dig down further on this?