The Audio Random Container - 23.2 alpha feature release

Why would you stick with 2023.2? I know people say take one Unity version and stick with it, but you shouldn’t do that with TECH releases, you should ride the wave towards LTS if you start using TECH.

1 Like

Hi there. I’m sorry you are hitting these issues when using the Audio Random Container. We have definitely not abandoned it. As @Jonathan-Westfall-8Bits noted, there are are many fixes in 2023.3 that should improve the experience greatly and there are more coming. Any of these fixes that have not been backported to 2023.2 yet will be ASAP. We want the feature to be as stable as possible.

As for the job temp alloc warnings you posted a screenshot of: are you getting these when working with prefabs? If yes, it’s a known issue and it’s on our radar. Though admittedly annoying, these warnings should not affect the functionality of the ARC. Can you elaborate on the issues you’re having with your run cycle?

As for why the UI is in a separate editor window rather than the inspector, as @Mikkel_Munch-Christiansen posted earlier in the thread, that was a design choice. The feedback has been noted (we know it’s a recurring one), but this will not change in 2023.2 or 2023.3.

Those temp alloc warnings are pretty bad, and it’s something that comes up in a lot of different instances. There’s no guarantee that @s4lt3d is getting these warnings from the ARC, it could be some change in the editor UI or whatever that just happens to be triggered by this version.

You really need to improve what information is in there, as “something is wrong somewhere lol” is not helpful information. Unity is riddled with these kinds of errors and warnings with no stack trace, no information about which subsystem sends them, or no information about which asset/object the error relates to.

I’m talking about things like
“[worker(0)] can’t create a directory out of process”
“Some mesh has some bones with no weights”
“There is some allocation that’s long-lived!”
“SerializedObject target has been destroyed.”

You should really just sit down with the entire code-base, search through every single call that outputs information to the console, and ask the question “is this information actionable in a real project?” If the answer is “no”, add whatever information’s required, or delete the output.

No disagreement here, warning and error logs should provide useful information. And you are absolutely right, the root cause for that warning could be something else.

ARC issue tracked here.
Other issue that results in the same warning, but different cause.

Sorry I somehow skipped over this question. My apologies.
For the current moment on our teams commercial project we are working on updating to 2023.3 because of the render graph. We have a branch on both 2023.2 and 2023.3. I agree with you on riding the tech release wave. We just have to convert more stuff over to render graph (been super easy and simple so far), do some checks on a WebGPU build, and lastly finish up some updates for certain UI Toolkit stuff.

But so far the audio container is a lot better in 2023.3 in every way possible. I don’t have any bugs and we have not noticed console logs, visual bugs in inspector for the audio container, or audio issues in build except on for WebGPU builds. The WebGPU builds bug is honestly more related to the core audio than just audio containers, but I think I saw a notification saying the bug was found and a fix is already being done.

1 Like

Hey, just thought I would let people know in the patches notes today for the newest version of Unity 6 had some of the previous mention fixes that were coming down the pipeline. Uploaded an attached image with three of the ones that some people asked about.

Not sure when or if they are already coming down, but they might be being backported already to Unity 2023.2. Not sure yet on that timeline or if the work for backporting is already started, but thought people might be happy to see the bugs mentioned are fixed in some areas.

Main ones that were fixed in the Unity 6 version for some are probably the console spams and the null reference error spamming.

I just want to clarify that the scene I was working in had very few items in it and nothing that used jobs. The errors came up only when using ARC and the sounds overlapped as the footsteps would repeat quicker than the length of each track. This warning was spammed to the console which is a no go for any project. I was playing around with the new system for making footsteps for a player controller in a grey boxed scene. The warnings came up only when using ARC. It’s not great to see warnings every time the game is played as it will cause warning fatigue and developers will start ignoring issues in the editor.

The “opens in a separate window unlike almost everything else in Unity” is just like the Audio Mixer Groups window. Very confusing for newcomers. If you’re going to lean into this “audio is a system, not an asset” mindset, then get rid of the stupid singleton “Audio Listener” component which also trips up newcomers, and just mix all active listeners.

1 Like

Agreed, and if this is indeed the issue, a fix is in progress.

Were the sounds overlapping when the automatic trigger mode was set to offset or pulse? If it’s the former, there should be no overlap and it’s a bug. If it’s the latter, then it’s intended.

Or were the overlaps you were experiencing more a “bunching up” where many clips would suddenly be playing all at once?

@s4lt3d A fix for the memory leak warning spam has landed in 2023.2.17 and 6000.0.0b13.

Is this Audio Random Container feature going to be available in Unity v2022.3.x?

No, it is only available from 2023.2 and on.

Will it support the use of playOneShot?This would be truly useful for me, as I prefer not to implement pooling methods myself. Additionally, it would make previewing sound effects in character animations during edit mode much more convenient.

So depending on how you are needing PlayOneShot it is already supported in some cases.

Edited a huge add on to the original post to make it unviersal set up.

Example lets say you have a set of random sound effects that when something happens one of them is chosen at random to play. That is already supported via the following set up.

Setting in Audio Random Container

  1. Trigger to manual.
  2. Playback mode to random
  3. Turn loop off. Some cases you might want loop to be set to cycles mode with a value of one.

Than just on the Audio Random Container you are using as a pool just tell it to play.
With Playback mode set as random it will never remove the clips from the pool after playing a clip. While if you did want the clip to be removed from the pool you can set it to shuffle mode.
Side note when all clips are played they will be readded back to the pool on shuffle mode.

Could you give some information about your use case for PlayOneShot? Depending on what it is you just have to tweak the settings of the ARC asset in the inspector than just call play like normal and it will play your clips from a pooled system to save memory.

Edit s below.
Do note Audio Random Container and audio clips both now inherit from the new base class for most audio specific assets called Audio Resource.

In the AudioSource asset you can pass in any type of AudioResource in the inspector for it’s clip so you can assign the Audio Random Container to an audio source as it’s audio asset.
Than on that Audio Source just do normal play and the AudioSource will now use the audio clip pool inside of the Audio Random Container.

For the API of AudioSource.PlayOneShot you can technically pass in the audio clips that are pooled inside of the ARC Asset., but I think this second method still creates a new gameobject sound effect.

Probably best choice is to have the ARC asset use an extension method and add a short PlayOneShot extension method onto it via code. Do note you use the AudioSource API to play the audio clips to ARC assets. Link below to the documentation page for it.

Basically you just add a new extension method that uses an AudioSource passing in an AudioResource instead of a AudioClip. ARC inherit from AudioResource or used to. I know they made some API private now unfortunately when it was originally public.

Than in the extension method you just have the AudioSource play the current set clip or add in logic to play a specific clip of your choice from the pooled set of audio clips inside of the ARC asset.

https://docs.unity3d.com/6000.0/Documentation/Manual/AudioRandomContainer-fundamentals.html

Without PlayOneShot, I can’t play two AudioResources simultaneously on a single AudioSource.

For that use case you can make an extension method that just adds a utility method that calls PlayOneShot and passes in the clip from the AudioContainer. Should only be a couple lines of code.

Audio Random Container is not public, but internal. Even if I use an extension method, I can only access its variables and methods through reflection. However, after decompiling with Rider, I couldn’t find anything that returns a random AudioContainerElement or random volume and pitch. I don’t quite understand this, as Audio Random Container is perfect for handling short sound effects like gunshots or hit sounds. For an AudioSource, Play is more suitable for playing background music, while PlayOneShot is more suitable for sound effects. However, Audio Random Container doesn’t support PlayOneShot. So the only solution I can think of, like the person above mentioned, is to create a similar feature myself using ScriptableObjects—an Audio Container that supports PlayOneShot.

2 Likes

I can’t get any info (such as its total length) about the current clip that’s playing if I use an AudioSource to play an AudioRandomContainer.

1 Like