USoundNode ParseData override crashing with Procedural Sound Wave

Development Audio
, , , , ,
1

Attempting to use the USoundNode Generate PCM Data override causes crash:

void UMySoundNodeTest::ParseNodes(FAudioDevice* AudioDevice, const UPTRINT NodeWaveInstanceHash, FActiveSound& ActiveSound, const FSoundParseParameters& ParseParams, TArray<FWaveInstance*>& WaveInstances)
{
	if (AudioDevice) {
		// method 1 : works "sort of" , but seems like the clip stops playing and restarts
		if (!SoundWaveIsInitialized)
		{
			CreateSoundWaveStreaming();
		}

		if (SoundWaveIsInitialized && SoundWaveProcedural) {
					SoundWaveProcedural->Frequency = Frequency;
					SoundWaveProcedural->Volume = Volume;
					
					SoundWaveProcedural->Parse(AudioDevice, NodeWaveInstanceHash, ActiveSound, ParseParams, WaveInstances);
			}
	}
}

^^ Code causing problems. It always crashes on SoundWaveProcedural->Parse(AudioDevice, NodeWaveInstanceHash, ActiveSound, ParseParams, WaveInstances);

With most of the code lifted directly from here: Procedural Audio - C++ - Epic Developer Community Forums

I have tested various things (WaveInstances->Num() > 0) seems to be a good check, as it’s Zero.

Edit:

The whole Editor crashes when I hit attempt to preview it, with an Actor that has a Sound Component attached wherein the actor is to play the cue.

2

So, as some more information: This is an issue with 4.12.5 as well. My guess is that I need to fill the queue with bytes. The question is how, and I’m currently poring over engine code to figure it out.

So far, going to the base “USoundWaveProcedural” class which my thing inherits from, it works again, and I’m looking at why. What I want to do is make the class generate a soundwave on its own, algorithmically. And without FMOD/WWise. It’s sad you have to rely on 3rd parties for better audio in the engine.

3

Some ramblings as I’ve made progress. One of the things that annoys me about Unreal Engine is the ridiculous use of private when protected would be a much better option. If a virtual void function in the base class uses a variable, then that variable should be protected or public, it should NEVER be private.

4.13 and 4.12.5 SoundWaveProcedural for example, has TArray QueuedAudio; as PRIVATE. any person who wants to extend the class’ data for their own use has to do it via the source code of the engine, with rebuilds, etc. Luckily changing scope in a program is all for the compiler so basically nothing changes as you change it.

I mention this, because in order to have a working function, I was trying to use the original SWaveProcedural class and basically copy the code over, but stuff like PumpQueue() are declared as private. That’s just silly.

While not being an answer, I’m going to download 4.13 from source.

4

Hey Dwood,

I have gone through whats in the forum post and it is a bit outdated, which isn’t a huge deal. With that said, I am not sure what part of the cod you posted is overriding GeneratePCMData( ).

Furthermore, I am not sure what part of your code would be considered a bug with the engine, as it mostly appears to be your code.

Please update your post with more information regarding you issue, specifically how it is a bug with the engine.

Thanks.

5

Hi Dwood,

Not sure if you’re the same person who asked on the other UE4 forum, but I responded in depth over there today.

Stop using private variables in virtual functions please! - Feedback & Requests - Epic Developer Community Forums!

One of the things that annoys me about
Unreal Engine is the ridiculous use of
private when protected would be a much
better option. If a virtual void
function in the base class uses a
variable, then that variable should be
protected or public, it should NEVER
be private.

Actually, UE4 has a history of the exact opposite problem where everything is public, especially in the audio engine. In general we are trying to move the audio engine toward explicit access modifiers (and not make everything public), not only because it’s better in general to have accessors for data (to decouple implementation details from client code), but because the audio engine is now significantly more complex due to the new threading architecture. By making that data private in USoundWaveProcedural, it’s forcing the user to consider whether or not they really need to use the data and/or if they might instead let the base class handle the operations.

However, that said, in this case I’d be willing to change the access modifier back to protected since presumably if you’re implementing a USoundWaveProcedural object you’re going to know what you’re doing.

6

It’s sad you have to rely on 3rd
parties for better audio in the
engine.

Apologies for not meeting your standards. For what it’s worth, I’m the only audio programmer at Epic (and the first dedicated one ever as of a little over a year ago) and I’m trying to alter course on a huge amount of tech with 20+ years of momentum and tons of existing dependencies.

In addition to being the tech support for all our licensees and our internal game development (with 4+ games under development at Epic), I’m current working to get out from under the weight of deep platform dependencies. We have 9 platforms and counting and each platform has significantly different implementations with widely variant feature support for audio.

To that end, I’m designing and implementing a new, multi-platform audio engine back-end so exciting next-gen type work can be done across all platforms at once with true platform parity.

There’s also a huge number of 3rd party vendors and folks like yourself who have the skills and are just itching for the ability to do really amazing things with audio in UE4 but just aren’t able to (easily) in the current tech. Incidentally, the first version of the new audio mixer is schedule to make it out to users for 4.14 (in a opt-in-only mode).

7

However, that said, in this case I’d be willing to change the access modifier back to protected since presumably if you’re implementing a USoundWaveProcedural object you’re going to know what you’re doing.

Don’t change anything in the end builds just for me quite yet! If there is more clarity on how to use soundwaves more effectively in the source code and such, I WOULD appreciate that more than just changing things around. I was frustrated in trying to find useful information on audio generation and Sound Node usage. Now that I have a response from you, If you take a look at the forum thread in a bit, I’ll have a better reply for you there. For anyone finding this thread from a search engine, the thread is here:

Stop using private variables in virtual functions please! - Feedback & Requests - Epic Developer Community Forums!

8

I’m unable to isolate the problem with my own code, and therefore would like feedback on setting up my own USoundWaveProcedural child and an owning USoundNode child to avoid the crash I’m having on ParseNodes, so please don’t close this thread until then, as I’m still getting crashes.

9

For anyone finding issues with USoundNodes: in your ParseNodes override, don’t merely call the SoundWave’s Parse function. You’ll have to do a bit more to set that up, I don’t know what that is as I haven’t done it (look at some of the hardcoded nodes I suppose). I am, however moving to a different layout for my goal of procedural audio generation, suggested by Minus_Kelvin here:

Stop using private variables in virtual functions please! - Feedback & Requests - Epic Developer Community Forums!

10

Hey Dwood,

Thank you for submitting a bug report, however at this time we believe that the issue you are describing is not actually a bug with the Unreal Engine, and so we are not able to take any further action on this. If you still believe this may be a bug, please provide steps for us to reproduce the issue, and we will continue our investigation.