Listener Position not updating?

I’m trying to determine why Concurrency Resolution Rules (in a sound cue) don’t seem to be applied when I have more AmbientSound actors in a scene than I have active voices.

Using the ‘stat sounds -debug’ console command, seems to indicate that the Listener Position (XYZ) isn’t changing as the player moves around in a scene.

I’ve seen the same in my own project, the First Person Shooter, and the Third Person C++ template projects.

I’ve also tried using the Blueprint ‘Set Audio Listener Override’ using the First Person Camera Component.

Attenuation of sounds seems OK, even though the listener position in the debug output isn’t updating.

I’ve had similar problems for a couple of years now, I’d assumed that Concurrency just worked differently to how I expected it to, but the extra Resolution Rules (added recently?), seem to suggest my original expectation for voices to be discarded and restarted based upon the current rule, suggests that such WAS supposed to happen based upon the player/listener position.

So if the listener position in the debug isn’t updating, could this be why the concurrency isn’t working? If so, can anyone suggest what I might have overlooked to have the listener update? If the templates are lacking something important, could they be updated?

Confused…

So, from what I can tell the engine never fills the Listener position in the AudioStats structure in an AudioDevice. So it’s not updating isn’t useful information in relation to trying to work out why Concurrency Resolution Rules aren’t being applied. I don’t have a great deal of time to dig into the engine, which is why I chose UE4, rather then continuing to develop my own. So if someone out there could point me in the right direction as to how Concurrency Resolution Rules are supposed to be working, and suggestions for why they aren’t it’d be greatly appreciated.

Latest installment in trying to work out how Concurrency for sounds is supposed to work -
I’ve determined that ResolveConcurrency is only called on AmbientSounds within a level when the level is loaded and when it’s unloaded.
I’m not sure how having concurrency only checked at these times is useful. ResolveConcurrency isn’t called at all in between, at least not on the sounds I’m testing using StopFarthestThenOldest…
I would expect the concurrency manager to allow ambient sounds in excess of the max voice setting, to be actively disabled where the concurrent setting indicated such, as a listener moved through a level. This doesn’t appear to be the case???

Hey Gavin1969,

Apologies for replying to this so late, was just was notified of this thread.

So, concurrency evaluation for “stop-quietest” rule is supposed to be dynamically evaluated. In fact, ambient sounds were one of the motivating cases for the concurrency feature.

Unfortunately, there was a bug where concurrency evaluation would stop an active sound and the active sound would never regenerate. This was fixed for 4.14, which is coming out very soon.

For the other resolution rules, it’s not exactly clear to me how they would work to be continually evaluated ambient sound actors – other than the two stop-furthest rules. Currently stop-furthest rules do only evaluate on onset. The good news is that for 3D sounds, with 3D distance attenuation, if you use stop-quietest (and you have my bug fix!), you’ll be able to recover the identical behavior of what you would expect for stop-furthest. However, I’ll add a feature request to make the stop-furthest flavors update their the concurrency evaluation for 3D sounds since it does make sense!

Note that the concurrency feature is a relatively new feature for UE4 and is based on the prior concurrency system (which evaluated concurrency per sound instance not in a group). Other than the stop-quietest rule (which is totally new), the other resolution rules were always evaluated on sound onset so when I did the new concurrency feature, I simply transferred their old behavior to the new feature (but with the ability to limit concurrency as a group).

Thanks for getting back to me.

Yes, I noticed from the source code that stop-quietest was implemented separately, but in testing with 4.13 it still didn’t work - I assumed because a sound not being played at all is going to be the quietest! :slight_smile:

I’ve managed a quick test in 4.14, and it seems that stop-quietest should do the trick, now your bug is fixed. But other bugs in 4.14 are stopping me upgrading my project right now.

When I can manage to ‘safely’ upgrade to 4.14, I’ll update this thread to confirm such is working.

Note, there’s still a bug where the listener position that is shown with the stat sounds -debug consoled command isn’t updated. The command reads from a sounds stats structure, but the engine never updates the property.

Thanks again,
Gavin