Audio Mixer in addressable assets

Unity Engine
,
1

Is there a proper solution when it comes to serializing audio mixers in addressable assets?

I have one audio mixer that is used for addressable assets and non-addressable assets. I would like to set the volume/mute all of the sounds, but it seems to only affect the non-addressable assets. It almost looks like addressable assets reference a clone of the audio mixer.

We have the original mixer:

6549565--741175--Screenshot 2020-11-22 at 12.56.50 pm.png

We add the sound group to an audio source of an addressable asset:

6549565--741178--Screenshot 2020-11-22 at 12.57.11 pm.png
6549565--741178--Screenshot 2020-11-22 at 12.57.11 pm.png826Ă—154 7.9 KB

If we play and use existing addressable assets, the master mixer shows this:

6549565--741181--Screenshot 2020-11-22 at 12.57.21 pm.png
6549565--741181--Screenshot 2020-11-22 at 12.57.21 pm.png828Ă—524 16.7 KB

Audio profiler also suggests that there are now two identical mixers:

6549565--741184--Screenshot 2020-11-22 at 1.10.04 pm.png

I’ve found a related forum post , but those solutions are a little whacky.

2

I also have the same problem. Seems like the Audio Mixer referenced in the addressable assets are the different one from the one referenced by the non-addressable assets. I did a hacky fix by:

aaAudioSource.outputAudioMixerGroup = nonAAAudioSource.outputAudioMixerGroup;

Make them use the same Audio Mixer

1 Like
3

Same problem here.

4

I’ll raise this with the team for a bit of guidance.

5

Yeah this is a problem with how Addressables deal with ScriptableObject duplication.
If you run the analyzer tool, you should notice the mixer displayed as a “non fixable” scene duplication issue.
Which means, Unity will duplicate the mixer for addressable assets and use the original for scene assets.

Solution…

  1. Don’t reference the Mixer in addressable assets. Instead, use a static Singleton which Addressable assets can query to get the mixer.
  2. Don’t reference the Mixer in scenes. Always load the mixer through Addressable assets
  3. Make all scenes addressable
1 Like
6

CDF is correct, you will be duplicating the Objects. Addressables and the Player builds do not know of any content between each build.
Marking all Scenes are Addressables as with CDF’s point 3, will be the easiest way to keep your content in sync. Then have a bootup scene that loads your initial Scenes using Addressables, with them from local Addressable groups.

One thing to note is that the AudioSource has a reference to the Mixer. If the Mixer is not marked as Addressable. Then it will be included with the AudioSource as an implicitly included Asset (As everything in Addressables must be included). This can lead to lots of duplicated Mixers for each implicitly included AudioMixer from AudioSource reference. To stop this duplication across different Addressable Groups/Packs also, the Mixer should be included in Addressables.

3 Likes
7

@andymilsom Ah well that makes sense, thanks for the details.
I’ve tried it in my current project and it does work. :sunglasses:

8

So this implies the Play On Awake feature of AudioSource just cannot be used with Addressables since the Output mixer group must be set via script - right?

Not a fan of these core workflow workarounds.

9

You don’t necessarily need to set via script. It is just to avoid multiple copies of the mixer why you do above.

If you have Player Scenes and Addressables content referencing the same audio mixer, you may have the following:

Player:
SceneList

  • Scene 1 → AudioMixer (1)

Addressables
SceneGroup1

  • Scene 2 → AudioMixer (2)
    Other content,
  • MixerManipulationScript → AudioMixer (3)

Where in the Editor each part above references the same AudioMixer. At runtime they will be separate copies of the same AudioMixer. So if say “Other content” was a script that edits the AudioMixer and expect (1) and (2) to be affected, will not actually change the mixers (1) and (2).

This happens because Player content and Addressables content do not know about each other. In Addressables when you build each bundle, if there are any references to Assets that are not explicitly assigned to Addressables then it will be included as a copy.
Because of this, we recommend you A, use Addressables instead of the Player Scene list and set them as local. B use the Analyze rule to detect duplicate dependencies and set any you do not want as duplicated to an Addressables group.
Resulting in like the following, where the Scenes are in Addressables and AudioMixer is assigned to “Other content” group.

Player:

  • Bootup scene only used to setup

Addressables
SceneGroup1

  • Scene 1 → Reference to “Other content: AudioMixer”
    SceneGroup2
  • Scene 2 → Reference to “Other content: AudioMixer”
    Other content,
  • MixerManipulationScript
  • AudioMixer

Now when the “Other content” edits the AudioMixer, it will be the AudioMixer that is used elsewhere instead of copies.

10

Sure but realistically duplicate mixers are not shippable in a quality game - user facing audio level options are a basic requirement, meaning option scripts need fixed references to the mixers.

The core workflow is: object’s prefab sound references mixer A via inspector. Mixer A exists in scene. Spawn object. Audio plays on awake using mixer reference.

When that object is an addressable that is loaded and spawned the core workflow is broken, right? A copy of the mixer is created and the options script will have no reference to it. Something must reset the mixer reference, right?

11

Only when the Mixer is not marked as Addressables (AFAIK AudioMixer is an Asset and does not exist in a Scene). So long as the Mixer is in Addressables, and the Content that references the Mixer is in Addressables. Then all of the content will reference the same Mixer object.

12

I had an AudioMixer flagged as addressable but it is loaded via a reference in my launcher scene - this led to Mixer duplication. Does that mean the Mixer has to be loaded by addressables for the addressable references to work the way you describe?

13

If that Scene is in Addressables that it will be fine.

Yes, anything outside of Addressables will be duplicated. Though references to the Mixer from content in Addressables is fine.

14

The Mixer is in my launcher scene - the one scene in the build list, and so not addressable. So to make this work the way you all intend I would need to load the mixer into my launcher scene via addressables, right?

I’d like to reiterate that this kind of workflow is not good.

5 Likes
15

I can agree that this is quite an unexpected effect. Addressables shouldn’t be an all or nothing solution (e.g. make all scenes addressables).

1 Like
16

This was a pain to fix and after spending some time here’s the easiest “fix”.

Note, we didn’t want to make our scenes addressables as this would have changed the workflow for our entire project.
Our project uses Addressables for levels and enemies, but the scenes, ui, etc are not addressables.

  1. Create a singleton to store your audio mixer.

  2. In the singleton, you can either load the AudioMixer as an addressable or choose to use the scene reference.

  3. Choose one of the following:

If you choose to use Addressables (i.e. AssetReference), then you should add a component to every scene AudioSource to set the mixer group at runtime.

If you choose to use the scene reference audio mixer, then you should add a component to every Addressable prefab that has an audio source to set the mixer group at runtime.

  public class MixerSingleton : MonoBehaviour
    {
        public static MixerSingleton Instance;

        [SerializeField]
        private AssetReference _mixerAddressable;

        [SerializeField] private AudioMixer _sceneMixer;

        public AudioMixer Mixer { get; private set; }

        public void Awake()
        {
            if (Instance == null)
            {
                Instance = this;
            } else if (Instance != this)
            {
                Destroy(this);
                return;
            }
            DontDestroyOnLoad(this);
            
            // Choose one
            SetupSceneMixer();
            // SetupAddressablesMixer();
        }

        private void SetupAddressablesMixer()
        {
            Addressables.LoadAssetAsync<AudioMixer>(_mixerLoader).Completed += OnCompleted;
        }

        private void SetupSceneMixer()
        {
            Mixer = _sceneMixer;
        }

        private void OnCompleted(AsyncOperationHandle<AudioMixer> obj)
        {
            Mixer = obj.Result;
        }
    }

We went with using the scene reference to the AudioMixer as there was many more AudioSource in scenes to set the group for then there were Addressables. So the idea is to update the addressable AudioSource mixer group to the group from the scene reference at runtime.

5 Likes
17

This is so painful … Really, adressable is a good thing but it should provide basic implementations (opt-in if you will) to avoid having to handle this or shaders manually. What a loss of time and energy.

2 Likes
18

Me think the same way… 2024 still lot of misc stuff need to be done in manually. I was hope these new feature help dev solve problem not cause more. especilly these know-how is not point out on any of official document, dev need to find a way to solve it by flesh and blood…

2 Likes
19

i just went to this problem and having a hard time understanding why it goes like this… glad i found this post
I already using addressables because it’s good and it’s the new standard moving forward (or at least I’m told by my coworker), so seeing problem as simple as this, at least in my point of view, is kinda painful

1 Like