Audio ignoring audio priority?

I have an audio source playing ambient noise with priority 0, high priority. This is specifically recommended in unity documentation for things like music.

I have a bunch of other objects that I’m spawning that have their own audio sources. You’ll pretty much never hear more than a few playing at once, but their priority is all lowest, 256. They had their PlayOnAwake set to true (on accident) and so were playing when spawning in, all out of “earshot”. But this audio was canceling out my ambient audio.

Following breadcrumbs, I came to be running this code:

    private void Start()
    {
        StartCoroutine(DebugTesting());
    }

    IEnumerator DebugTesting()
    {
        yield return new WaitForSeconds(5f);
        audioSource.Play();
        if (audioSource.priority == 0)
            Debug.Log(audioSource, audioSource.gameObject);
    }

When my objects all spawn in, after 5 seconds, my priority 0 ambience gets cut off and the debug log returns nothing because all the object’s audio sources are priority 256. I can make it so they don’t spam play all these sources, but I’m trying to understand what’s wrong and cannot figure it out.

That’s interesting! I think I already heard an engineer call that voice stealing.

If you have a high number of these sounds, something exceeding AudioConfiguration.numRealVoices and maybe event .numVirtualVoices, it’s possible that the engine still tries to give them a chance to play and bumps the high-priority sound at some point, based on distance or other parameters…

But I’d like to clarify your issue on something, after that wave of low-priority sounds is passed, is your ambiance starting again? How many of these low-priority sounds are played and what does you AudioConfiguration look like?

Thank you for bringing this up!
Cheers!

Hi, I’m coming back to this and have been trying to figure out more of the audio system. Before I start reporting more issues, is it supposed to be the case that inaudible audio takes priority over audible audio? I have audio sources that are well out of range, completely inaudible, that are taking precedence over adjacent audio with volume.

The priority supersedes audibility, so an audible sound with higher (closer to 0) priority should always be first.

The screenshot you bring seems to show that this is not what’s happening, please check carefully that that no script or package or plugin might be influencing this first. I’d be curious to see if it’s related to the AudioMixer, if you do anything else with it than assigning the AudioSource to a group.

Then I’d suggest you experiment with AudioClip load types, as they have shown to influence virtualization in certain situations.

If nothing comes up, I recommend you try to isolate and reproduce this issue in another project and submit it as a bug.

1 Like

Thank you, I assumed this behavior I’m seeing wasn’t supposed to be the case. I probably broke some dumb setting 8 months ago by installing a worthless plugin I never used and am I screwed for eternity. I’ll mess around and see what I come up with now that I know for sure it isn’t supposed to be this way. Thanks!

1 Like

Ok I discovered something a little wonky that may have affected your interpretation of my screenshot and subsequently my understanding of the virtualization process. So I want to be really clear.

Question 1 - If an object of priority 128 is playing, but completely out of ‘earshot’, does it ALWAYS take precedence over something of lower priority, even if the lower priority is within earshot?

Question 2 - That is to say, does a completely inaudible source not automatically virtualize when volume is 0 (in order to make room for lower priority sounds?)

Bug - I believe I did find a bug. The audio profiler displays priority 256 in the profiler as priority 0. I believe this was the case for my screenshot above, that the lines showing priority 0 (high priority, just to state) were actually priority 256.

1 Like

This is very interesting stuff you bring in! Thank you for investigating this :pray:

So priority takes precedence over audibility at all time.

The point you raise about 0-volume-virtualization, in my understanding, SHOULD be how things are done. I opened a discussion internally on the topic and I’ll catch you up on it.

And the 256 overflow priority thing is a good catch, we’ll validate that also.

Cheers!

2 Likes

We recently upgraded a large in-production project from 2021.3.36f1 to 2022.3.53f1 and started to experience a difference in audibility which can only have been caused by the Unity upgrade.

On 2021.3.36f1, even if we went over our max real voice count (32), the audio clip you see selected here would be audible (it would have a value for Audibility). This screenshot is from 2022.3.53f1 and you can see it has no Audibility. I feel like it should be audible and there is a regression?

We’ve downgraded back for now, but I wanted to make sure the issue was raised.

Hi @fendercodes,

There were changes made to the audibility code (we had a lengthy conversation on the topic here) which landed in 2022.3.18. It was a matter of performance at that point, so I believe this might be something else.

I understand the discrepancy you mention happens in a big project, so many things can happen in this context… Did you check if anything on an AudioMixer changed or something like it? I see that the sound appears to have volume but is not audible, maybe that’s because no sound is decoded… I’d recommend you have a look at the audio clip settings, playing with load type and compression can some time make a difference, it would be interesting to evaluate that.

Otherwise, to address this as a bug, we would need a sample project isolating this issue to correctly identify the problem.

Hi @ATMLVE,

It appears that 0-volume virtualization might not be enabled by default, we’ll be looking into that!

This phrasing makes it sound like this is a non-default option I can enable, is that the case? I have it on my to-do list to code up an automatic “pseudo-virtualizer” to Stop() sounds that are out of range of the audio listener.

@SeventhString Thanks for your response. We tried 2022.3.17 and it had the same issue. Nothing changed in the codebase when comparing 2021.3.36 and those versions. So its gotta be something in the Unity updates.

It appears that 0-volume virtualization might not be enabled by default, we’ll be looking into that!

Is this related to the issue we’re seeing? :thinking:
The volume parameter on the AudioSource component for those 3D clips in the distance (e.g. Fly Particles in our screenshot) isn’t set to 0 specifically but the Volume column says its not audible so it should be virtualised? That being said, on 2021.3.36 we didn’t see those clips being virtualised either, but the clip selected in our screenshot was audible.

In the current state of things, this option only appears to be available under the hood, in the engine native code. We’re currently discussing on how to address this, and I believe we should be able to improve this situation relatively soon.

For your pseudo virtualizer, to avoid needing to keep track of the time passed and update the position of the file accordingly when resuming, I’d suggest you let that happen at the system level and hack virtualization though priority instead. This way you could just keep track of the realPriority, set it to 255 (not 256 :wink: ) when you want to virtualize and delegate the rest of the logic to the engine.

No it’s not related, I was answering this to the OP.

I hear you when you say that it has to be related to the update, but we can’t start an investigation without a submitted bug report with a decent reproduction. If you’re able to reproduce this issue in a small project and isolate the problem, we can work on it. If you’re not able to recreate the issue in a controlled environment, it might indicate that something else in your project might be interfering.

1 Like

@SeventhString No problem. I submitted a bug report with a very simple project that isolates the problem. It’s super easy to reproduce. Case ID is IN-90584.

1 Like

@fendercodes

Thank you very much!

I am having the same issue, where the following:

an audible sound with higher (closer to 0) priority should always be first

Is not true. See this image (spliced somewhat to reduce size, there are more SFX in reality):

I tried completely removing the audio mixer, and experimented with different load types, both for the music clip, but also for the other audio sources present. Didn’t change anything. Also scoured the codebase for any potential rogue plugins that alter priority or virtualization but did not find anything. But at the same time, I have been unable to reproduce this issue in a separate project, which is a sign that potentially it is something specific to our project - or I am just missing some critical part of the reproduction steps.

The one thing that I was able to do, that appears to fix it, is to randomly distribute the priorities of the SFX such that they are not all clumped together on the same priority level. If I do that, then the music (or any of the ambient audio sources, also with priority 0) never seem to get virtualized.

Normally, all of our SFX are on the same priority level (128), but if I did something like this in the Awake function of the script that handles playing each audio source:

m_audioSource.priority += Random.Range(-30,30);

Then the issue of music getting virtualized sometimes goes away. But this is obviously not something we actually want to do, when it comes to SFX, the audbility should always determine whether or not they get to play, not the priority. Anyway, it almost looks like the engine “panics” when there are too many sources to choose from to virtualize at a single priority level, and instead chooses another source with a priority level it should not touch.

I can also say with certainty, that this started happening after we moved from 2020.3.45f1 to 2022.3.9f1. On 2020, this issue did not appear.

I would be very grateful for any sort of help regarding this issue! :blush:

Bumping because we’re running into this issue too, also having moved from a 2020.3.x version, currently on 2022.3.39f1.

Your post is helpful though; in our game we might be able to work around it by clumping different kind of sound effects into different priorities. It’s far from ideal, but it’s at least it’s something we can try in the interim.

Which issue is it you’re running into specifically? There’s a few floating around now

It’s exactly as love_wessman described.

All audio sources are at priority 128 (default), except for our music which plays on priority 0 (highest). When many sounds are playing (>32), the music gets virtualised for a few frames causing it to stutter even though it’s at the higher priority, and even though in the Profiler there are clearly some sound effects that are not audible at that point that are priority 128 that are not virtualised.

Assigning random priorities to playing sounds results in the music playing correctly, but is undesirable as new sound effects might cause existing sound effects to cut out if the new ones are at a higher priority.

We’ve worked around this by disabling audio sources when we think they’re far enough away that they are likely not audible anyway. This is what Unity claims to do with virtualisation, audibility and priority, except since it doesn’t seem to respect the priority, we’re doing it manually.

This has only been an issue since upgrading to 2022.3 from 2020.3.

Hey, we have a fix in for Unity 6, the backports are currently working their way through the system - we expect the 22.3 fix to land within the next few weeks. You can check the status here Unity Issue Tracker - Audio Source clip is not audible when exceeding a high number of active Audio Sources

2 Likes