Hi, I’ve been working on a dinosaur game project where we use a vocal wheel to have players emit a variety of different sounds. There’s an animation for each roar and sound notifies within the animation are used to play the roar cue.
Since the 4.11 update, the sounds have randomly refused to play when pressing the roar key. Some users report everything works perfectly, others say only specific sounds are malfunctioning. I’m really at a loss to understand what is causing this.
We first noticed that some sound notifies were set to play at zero or before on the timeline, this meant the sounds would not play at all. Having fixed that we were hopeful the issue would go away but still received reports of sounds failing to play.
After moving to 4.11, I initially had audio occlusion enabled. This caused sounds to repeatedly start/stop during playback so I disabled it on everything. The only 4.11-specific feature I’m currently using is the new focus attenuation which seems to be working fine (when the sounds actually play). The concurrency settings for all cues have remained unchanged and look identical to how they were pre-4.11.
Wondering currently where it’s a general issue with animnotifysounds ? Since other animations triggered such as drinking, eating etc. also fail to play on occasion and are not linked to the vocal wheel.
We haven’t heard any reports of anim notifies not working with audio – as you might expect, we use them quite a bit in paragon and fortnite.
After moving to 4.11, I initially had audio occlusion enabled. This caused sounds to repeatedly start/stop during playback so I disabled it on everything.
I know this isn’t what you’re specifically asking about, but if you have a case where occlusion is causing this, I’d like to know. All it should do is either attenuate the volume of a sound that is occluded or add a low-pass filter. It shouldn’t start or stop a sound. Though I suppose if you’re occluding a looping sound and it attenuates to a low-enough volume that it’s then voice stolen, then when there’s room again in the voice-pool, it could restart. In that case though, I’d believe that would be the expected behavior. It’s possible that I can add a flag to a sound that would prevent a voice from ever being stolen due to the voice limit.
Since the 4.11 update, the sounds have randomly refused to play when pressing the roar key.
So I don’t know the audio scene for your game, but in 4.11, there is a slight change to how the global voice pool does it’s voice sorting and it’s possible that you might have to adjust your audio a bit. Before, the voice sorting was performed entirely by priority (which almost nobody used, and is likely set to 1.0 in your case). This means that it was hard to control what actually became an audible playing sound and what wasn’t. We decided to switch that to a volume-scaled priority so louder sounds will naturally have “higher priority”. However, you can still set a sound to be a high priority sound (you can set the priority to any number between 0 and 100) and this should result in the sound getting sorted higher and not voice-stolen.
This tech, btw, combines with the focus feature so a sound behind can be reduced in priority (and thus voice-stolen in favor of higher priority sounds).
Hi dinosauriac,
I just entered a bug(UE-29149) for this answerhub post today. Do you happen to be using Montages or the PlaySlotAnimationAsDynamicMontage node to trigger the animations? The reason I ask is because you said many of the notifies were at 0 on the timeline.
-.
Yes, we are using montages for a lot of actions, the vocal wheel in particular uses them. I’m unsure if it’s a montage-specific problem though, because while most of the time animations which don’t use a montage (like a walking animation with sound notifies) behave perfectly, there’s been a couple of outlying reports from our users of footsteps being inaudible. The actions that do use a montage appear to be more prone to failure though.
Moving everything a frame or two away from zero seemed to make the sounds trigger a bit more reliably but they still fail to play a fair bit of the time.
The occlusion issue was something that confused me a lot. When playing in-editor everything would be fine but in-game it was as if a new version of the sound was spawned in over and over again for its duration. Almost like the old behaviour of exiting / entering a soundcue radius where it would reset to the start of the sound, but on turbo mode. I’ll try re-enabling it on one of the cues again and see if I can replicate the issue.
Looks like this has been fixed for a future release. I am going to push to get it into a 4.11 hotfix, but that depends on how safe of a fix it would be.
Let me know if you come up with any results after re-enabling audio occlusion.
-.
Almost like the old behaviour of
exiting / entering a soundcue radius
where it would reset to the start of
the sound, but on turbo mode.
That was caused by the looping sound stopping when you exit the radius and simply restarting as you enter. In 4.11, sounds will actually play at 0-volume (i.e. when you’re outside the radius) so that when you enter, it’ll simply turn the volume of the sound up (and not restart). So in 4.11, it should actually be starting/stopping a lot less.
As for it’s dependency on occlusion enablement, that’s super weird since all the occlusion thing is doing is either applying a user-specified volume scale or enabling a low-pass filter with a user-specified cutoff frequency (to make it sound muffled) if the sound is registered as occluded after a trace-call against geometry. If you do get weird behavior when occlusion is enabled, I’d like to see your settings and maybe get a project from you with the issue.
there’s been a couple of outlying reports from our users of footsteps being inaudible.
As I said, I suspect in these cases, your footsteps are getting voice-stolen by other higher-priority sounds (or sounds with bigger volumes). So by default, UE4 only plays 32 sounds at once (in total). If 33 sounds try to play, it needs to resolve the conflict. To do that, it priority-sorts all active sounds according to the product of their volume (after computing every gain stage) and the sound’s priority. If the new sound (#33) ends up being sorted higher than every other sound, it’ll play and the sound at the bottom of the sorted list will be stopped. If the new sound is lower priority after the sort, it won’t play. In normal cases for a game, hundreds of sounds are trying to play and only the top-sorted 32 are actually played.
So if all your sounds are the exact same priority (e.g. 1.0), then this sort is purely by volume. This means that if a footstep is occurring relatively far away at a lower volume while other higher-volume sounds are playing, it’s possible that the footstep will be sorted past the
This is probably fine for most cases, but if you want a given sound to have a almost guaranteed chance of getting sorted at the top of the list, you should set your priority to be higher than 1.0 (e.g. 50.0, or even 100.0).
Sorry, ran into length issue… continued…
Another way to have better control of your sound prioritization is to control your sound concurrency in smaller groups rather than use the global pool. This is the motivation for the new sound concurrency feature. Using the sound concurrency feature you can create groups of sounds that limit each other and you can impose a global limit on the number of sounds allowed to play in a given class before it gets to the global voice-limit of 32. This will provide better control so that you can have a much better idea of what sounds will actually play. In the case of footsteps, you can create foot-step concurrency group, decide to limit the concurrency by using StopFurthestThenOldest rule, and set the concurrency limit to something like 5 sounds. Since footsteps are typically shorter duration and the ones you really want to hear are usually the nearest ones, this will prevent the footstep sounds flooding your global voice pool (of 32) and you’ll probably be able to hear almost every footstep, assuming there isn’t some other crazy thing going on with your other audio. In that case, the audio scene is probably complex enough that some missed footsteps are probably not a big deal.
I haven’t been able to duplicate the occlusion issue, unfortunately enough, but from what i remember it happened when a sound was occluded by foliage. Swinging the camera from behind to in front of the foliage would make the sound start over.
I’m currently setting up some of the sound cues in a blank project and will migrate them over to see if that fixes anything, along with setting up a few concurrency groups and making the priority of the roars higher.
Ok, let me know if you do capture a repro.
Eventually I’d like to implement more robust debugging tools so you can more easily identify problems (on-the-fly muting and soloing sound classes, sound-cues, wave-instances, visualization, and real-time spectra and amplitude monitoring).
So, we’ve moved to the latest engine hotfix and attempted migrating sounds in from a blank project, setting up concurrency groups and setting the priority of sounds super high. Still having problems.
Just now I’ve been debugging the issue with my team and tried adding particle notifies to the animation to try and narrow down if it was an audio or animation problem. Most of the time, when a sound failed to play, the particle effect would also fail. Unfortunately it’s not 100% conclusive since there were still some instances when the roar played but the particle didn’t, and vice versa.
Video of bug in action:
With stats on-screen:
Check out “stat soundwaves” or “stat sounds” to see a list of playing sounds. “Stat soundwaves” will show you the actual sounds that are playing. The stats display you’re using is more for CPU performance and not sound asset debugging.
New video profiling the issue:
Roars still randomly refuse to play. We’ve made multiple concurrency adjustments, rebuilt them in a new project and migrated them over, turned off 4.11 specific effects, increased their priority a hundred fold, artificially prioritized them, made sure they’re not set to zero or earlier on the timeline… we’ve tried about all we can think of.
Hey dinosauric,
This video definitely seems to be the same as UE-29149. That is going to be fixed in 4.12. Unfortunately, the fix was deemed too dangerous to move into a 4.11 hotfix.
-.
If that’s the case I’ll report back if/when the issue is resolved with the 4.12 update. Here’s hoping!
Thanks again for taking the time to look into this.
If you’d like to test out converting a copy of the project to 4.12 latest to see if it is resolved there.
We updated to 4.12 yesterday and the issue still persists. If anything, it has gotten worse.
The animations themselves refuse to play sometimes now, not just sounds. This seems to occur when combining different animations together, such as trying to roar whilst sprinting.
Hey dinosauriac,
I wasn’t the tester for that bug, but I decided to run it again with my existing test project. It didn’t work, however, when I recreated the notifies or duplicated the animation sequences, it resolved the issue. Can you try that out to see if it resolves the issues?
-.
Thanks for the suggestion! I tried out replacing the notifies in all the animations and from the testing we’ve done so far it seems like it might have fixed the issue 
The other problem I mentioned about the animations failing to play full-stop I think is probably an unrelated issue, it only seems to occur during high ping situations.
Awesome! Glad that helped.