Virtualized sounds do not update MSS parameters when Virtualization is disabled

Development Audio
, ,
1

Hi

We have been having an issue when certain sounds enter attenuation range quickly, either by moving fast, or the player teleporting to them. There is alot of bespoke audio setup on our project so we are trying to narrow down the cause. As part of testing, i focused on virtualization and have noticed that:

  • if a sound plays, then becomes virtualized (due to going out of Att, restart behaviour), virtualization is then turned off and the player re-enters att range, none of the MSS parameters are updated.

This seems to be exactly what is happening in our case and while we are forcing it with a console command, the outcome is exactly what we are experiencing. So i’m trying to determine if this is a bug, or something expected/known. This should hopefully help narrow down the cause from our end. It possible we are reusing an Audio component that previously had virtualization disabled and this is a symptom of this, but the behaviour shown here seems undesirable

See the video attached for a demo and a bit more explanation.

Any help/insight appreciated

Thanks

Steve

2

Steps to Reproduce

3

I meant to record myself speaking over the vid but in true audio engineer fashion, the input was set to something else. Here are step to repro what i show in the vid

  1. create a MSS that has inputs to be modulated - in video, i’ve used pitch over distance as was an easy setup
  2. play mss in level and notice the inputs are updated as expected
  3. leave Attenuation range and notice sound is virtualised as expected
  4. use command au.VirtualLoops.Enabled 0 to disable virtualization
  5. re-enter attenuation max distance and hear sound
  6. notice the inputs are no longer updated as expected

For some reason when a sound in unvirtualized it just stops updating inputs - our issue is likely due to something similar (as we see this behaivour) and understanding what is happening here would likely help us diagnose the prblem

4

Hi Steve, apologies for the delay. I am looking into this now and will get back to you with an explanation of what’s going on soon!

5

Thanks, have been on vacation so posting to re-open, looking forward to any updates on this

Thank you

6

Hey Steve,

We’re digging into this, and we have the bug identified, but it’s not a trivial fix. Part of the trouble is that when you dig into the behavior like this when setting these CVars at runtime, you are bound to run into issues like this, and so they’re not really intended to be used in this way. Is the CVar a critical part of this repro, or are you doing something else with Virtualization which creates similar behavior?

7

Hi Alfaroh, I can take over comms on this bug from here.

We integrated a pooling system and found sounds coming out of virtualisation would not get their inputs updated in runtime. Our biggest offenders were vehicles where we are constantly updating float inputs for attenuating and spatialisation. Toggle the CVar in steves video was purely to showcase the issue.

For the time being we’ve disabled our pooling system and have only seen this happen a small handful of times so it definitely gets exaggerated when its on. We was hoping that you might have some insight on how this could possibly happen?

Thanks

Sean

8

Hi Sean,

Could you elaborate on this pooling system? Does it change the Virtualization mode of sounds while they are virtualized? Basically, I am trying to understand why disabling virtualization was part of the repro steps.