Summary (TL;DR):
A looping sound inside an Audio Gameplay Volume stops being affected by AGV after leaving attenuation and returning from virtualization when virtualization mode is set to Restart. The issue does not occur with Play When Silent and did not exist with the legacy Audio Volume system.
Hello,
I’d like to report a potential bug related to audio virtualization and its interaction with Audio Gameplay Volume (AGV) in Unreal Engine.
Setup:
A looping sound with attenuation.
The sound is placed inside an Audio Gameplay Volume.
Virtualization mode set to Restart.
The initial state of the sound does not matter — starting within attenuation or starting already virtualized leads to the same issue.
Scenario:
The sound is actively playing while the listener is within the attenuation range.
The listener leaves the attenuation range, causing the sound to become virtualized.
The listener re-enters the attenuation range, and the sound exits virtualization and restarts (as expected with Restart mode).
Expected behavior:
After exiting virtualization, the sound:
restarts,
continues to correctly respond to Audio Gameplay Volume (Attenuation and Filter).
Actual behavior:
After exiting virtualization:
the sound restarts,
Audio Gameplay Volume no longer affects the sound (no Attenuation or Filter are applied), even though the sound is still within the AGV bounds.
Additional observations:
This issue does not occur when virtualization is set to Play When Silent (i.e. the sound never enters a virtualized state).
With the legacy Audio Volume system, sounds could freely enter and exit virtualization while still being correctly affected by the volume.
I’d like to ask whether:
this behavior is intentional, despite the differences compared to Audio Volume,
or if this is a known bug that is already being addressed and expected to be fixed in an upcoming patch.
Thank you for your time, and I appreciate any clarification or guidance on this matter.
Hey there Gustaw, do you mind sharing a pic of your setup (Soundwave/cue settings, attenuation settings, concurrency settings, if any)? This will give a better understanding of where the problem might stem from.
I would check that:
If your soundwave is wrapped in a soundcue, that the soundcue is set to “looping”, not just the soundwave
Concurrency settings are not allowing your sound to get out-prioritized when virtualized, and thus destroyed
Thanks for your reply.
I’ve prepared video to clearly demonstrate the issue.
I created two levels:
one using an Audio Gameplay Volume (AGV)
one using a classic Audio Volume (AV)
In both cases, the volumes are placed over the same blue floor area. In the video below, AGV is on the left and AV on the right.
As shown in the video, when using AGV, the sound is not affected by the Filter after being virtualized and then realized (I believe “realized” is the correct term here). In contrast, when using AV, the sound remains filtered after realization, which is the expected behavior.
I tested this with:
SoundWave
Sound Cue
MetaSound
All assets are looped, with Virtualization Mode set to “Restart”.
The assigned SoundClass has “Apply Ambient Volumes” enabled.
The video demonstrates virtualization caused by leaving the attenuation range, but I also tested other scenarios (e.g. concurrency-based virtualization) and the behavior is the same – the issue is not limited to attenuation-based virtualization.
I’m currently using Unreal Engine 5.5, but I also tested 5.7 to check whether the problem still exists. Unfortunately, it’s even worse there:
In 5.5, if the player spawns outside the attenuation range and the sound starts virtualized, the filter and other AGV effects are applied correctly upon first realization.
In 5.7, this is no longer the case – even on first realization, AGV effects are not applied at all.
Since the exact same setup works correctly with Audio Volumes but not with Audio Gameplay Volumes, this strongly looks like a bug specific to AGV.
I’d really love to see this fixed. Audio Gameplay Volumes are a major step forward compared to Audio Volumes – it’s a great concept and very powerful technology with many potential use cases. It would be great to be able to rely on them in production.
Hey there Gustaw,
I see the problem more clearly now and unfortunately I think this is a very niche case that probably doesn’t come up very often, which means I’m having trouble finding anything related to it, soooo….
Best Guess
When virtualized with Restart, the engine fully destroys and recreates the sound instance. When recreated, it may lose its internal reference to the AGV system or its volume filter/attenuation state, so AGV effects aren’t applied. This does not happen with Play When Silent because the sound instance never gets destroyed. Possible workaround:
Change to “play when silent” to keep the sound instance, but bind to the audio component’s “on virtualization changed” event and restart the sound from the beginning on realization. This keeps the behavior you want, but avoids the asterisk that comes along with it.
Given that the system is still considered “experimental” by Epic, it’s bound to come with some bugs, and this sounds like one of those cases.