I’ve been playing around with the Granular synth and just made a build (4.25.1, Win 64) and am receiving a nasty fatal crash when triggering a sound from my granular synth (Blueprints). Anything in particular one needs to avoid when loading samples into the Granular Synth? It’s an .aif file, everything seems normal; loads and runs fine PIE (VR/Oculus).
[FONT=Courier New]Assertion failed: SoundWave->GetPrecacheState() ==
ESoundWavePrecacheState::InProgress
…
…
Bad PrecacheState 0 on SoundWave…
Hi @robertkhamilton, I’m sorry you’re experiencing this issue. I was able to reproduce the crash. I don’t know what the scope is to fix it or which version it will be fixed, but I devised a work-around so you can continue working:
I was able to avoid a crash by adding an instance of my Granular Synth to the Level. I separated out the On Begin Play execution into a new Initialization Function/Event for my Actor. That way I’m not actually starting the synth generation allowing the one sitting in the level to be more vestigial and not actually take up a voice. Then when I spawn a new Actor with my Granular Synth, I’m able to do so without crashing.
I’m not sure of the exact reason, but the cause seems to be spawning a Granular Synth component without there having already been one in the level. Maybe some kind of execution order thing? Not sure. The difference between a PIE session and a Stand Alone Game is that the Stand Alone has a separate Audio Thread where the PIE session or in-editor game doesn’t.
So that’s the work around. I’m guessing it has to be the same SoundWave. Sorry this is sort of a not-great work around, but it is a work-around.
Thanks for the sleuthing @dan.reynolds. I’ll test that out and let you know how it goes. I’m in the middle of some other granular debugging also, so I may start flooding some questions here.
Just following up @dan.reynolds … successfully made a build in 4.25.3 after adding an extra instance of my synth BP to the scene. Not sure if that or any behind the scenes update in 4.25.3 made it work but it compiles and runs now. Thanks for the suggestion.
For my build, it launches successfully at the first time after build, then granular synth just wouldnt load everytime I launch later.
I tried both
adding all granular synth as instances to level bp
adding a new granular actor to level, and also instanced by level bp
adding an event, everytime I click R, the level restart all granular components
and here comes the problem: teh restart works during the first launch, then it never works again. So I guess it would be a “quit game” issue(maybe granular and sound waves are not properly stopped after closing the game?).
So I tested the quit game in editor, then my whole editor crashed:
Assertion failed: IsValidLowLevel() [File:D:/Build/++UE4/Sync/Engine/Source/Runtime/CoreUObject/Private/UObject/UObjectBase.cpp] [Line: 129]
I’m quite sure now it is Quit Game destroyed my actors…even in editor(though granular synth run smoothly in editor)
This is a show-stopping bug for us as well. Thanks for the workaround @dan.reynolds - it was enough for me to package a build and do some proofs-of-concept on our own custom audio component (which is also sample-based), but what really made it work was loading the required sample into the ‘dummy’ component on the Level BP, before loading it again into our component after our insrument actor had been spawned. Hopefully that’ll help someone else.
Very much not a long-term solution though - we need to be able to dynamically/programmatically read samples at runtime, and having to preemptively load them all into dummy components in a pre-init holding area won’t scale very well
Any possibility of this being looked at on Epic’s side, or any new clues about ways we can try to fix it ourselves? Oh - and has it been officially logged as a bug?
For anyone who’s following this, here’s how I’m ‘solving’ it for now. Inverted commas because this really isn’t a solution, and it’s not really a workaround either (in the sense that it won’t help if your project is all or mostly Blueprint based).
If your project is C++ and you’re trying to use SoundWaves at runtime on an arbitrary basis, ie it’s not practical or possible to preload every SoundWave via a dummy SynthComponent (Granular, custom, whatever), then you can use AudioDevice’s Precache method to get things going. Here I’ve set ‘true’ for bSynchronous (blocking Vorbis decompression), bTrackMemory and bForceFullDecompression because that suits me; YMMV. If PrecacheState == 0 (NotStarted) the audio data will be null - it’s possible that 1 (InProgress) will work, but in my use-case I can afford to block and wait for the whole thing to decompress (2, Done). Sample is a USoundWave* reference.
In the end, we had to write our own custom SoundWave PCM Loader and do all the precache state management (start, tick, update state, cleanup) ourselves. It was only worthwhile because we lean so heavily on this for a custom synth engine; it would be a horrible amount of hassle just to get the Granular Synth to work. I had to get our lead coder to help me out and there’s stuff he’s done that I still don’t fully understand, so I can’t be too specific here…
The ‘solution’ I posted last year ultimately wasn’t good for us because it hitches the game thread (that bSynchronous==true) and because we had loads of big samples to dynamically load at runtime, at arbitrary points in the game. You might get away with it if you can do some synchronous loading before the game starts on a few samples you know you’ll definitely be using with the Granular Synth later…
If you’re on (or can move to) UE5 and you can achieve the same thing in UE5 with MetaSounds I would say definitely do that.
Edit: btw, YufanXie’s problem might be related to the fact that in PIE, the precache status is managed by the Editor; the reason it works first time is that the Editor has already precached your soundwaves in order to allow preview playback in the content browser. Otoh failing the IsValidLowLevel assert is weird and sounds like a component hasn’t been registered or started properly, so is maybe a red herring…?
