AudioClip to FMOD not spatialized

I’m facing a weird issue where a Programmer Event won’t get spatialized at runtime.

Here is my static AudioClipToFmod class on pastebin.

I do update the event instance position in Update() like so:

EventInstance.set3DAttributes(transform.position.To3DAttributes());

And here are a couple screenshots from the FMOD editor:


Any idea would be much appreciated!

FMOD 2.02.11 + FMOD Unity 2.02
Unity 2021.3.17

Anyone?

Hi! Sorry for the delayed response over the Easter break.

Unfortunately, I’ve been unable to reproduce you issue - I’m able to create a programmer sound that spatializes properly with your code. That said, your setup in Studio looks fine, unless you have something downstream in the mixer that may be affecting or overriding the spatialization on the event. Can you confirm for me that you have no other spatializers in the mixer that this event is routed into? Also, is your EventInstance.set3DAttributes() call is setting the correct attributes? You can check this with EventInstance.get3DAttributes().

Hi Louis, thank you for the feedback and testing the code.

I confirm there’s no other spatializer in the mixer.

I also tried to log get3DAttributes and the position does appear to be correctly updated.

Not sure what to try next. Let me know if you have any other idea.

In that case, could I get you to package your FMOD Studio project and upload it to the “Uploads” tab of your FMOD Profile so that I can take a closer look and hopefully diagnose the issue?

I uploaded the project to the Uploads tab. Let me know if you need anything else.

Thank you so much for your help. Looking forward to your feedback!

After looking at your Studio project, everything seems to be in order, which makes me think that the issue is likely with the script that you’re using to make calls to AudioClipToFmod to play the Walkie Talkie event - i.e. where you’re calling EventInstance.set3DAttributes(transform.position.To3DAttributes()); in Update(). If possible, could I get you to provide the code for that script, or a stripped down version that you are still able to reproduce the issue with?

The rest of the code is straight forward and difficult to share at this point.

But from a WalkieTalkie.cs (Monobehavior) class, I call AudioClipToFmod.Play() like so:

EventInstance = AudioClipToFmod.Play(clip);

Then in Update() I do:

EventInstance.set3DAttributes(transform.position.To3DAttributes());

And if I add:

EventInstance.get3DAttributes(out var attributes3D);
Debug.Log(attributes3D.position.x);

I see the value being properly updated (0 at first, then varying only after calling AudioClipToFmod.Play).

That’s pretty much it. Really weird.

I agree, it is really weird. If spatialization is working in Studio (e.g. when adjusting the 3D preview, auditioning in the sandbox, etc.), then it should work in your game, as it’s functionally the same code under the hood.

If you manually change the position of the event (i.e. change the position of the GameObject that uses WalkieTalkie.cs) to be identical to the listener, and then slowly move it a large distance away from the listener, does your event spatialize and attenuate properly at all?

Additionally, there’s a number of other things that could cause the event to not be spatialized, or seem to not be spatialized:

  • You have multiple listeners in a scene - this causes blending between listeners, which will impact spatialization
  • Your event shares the same position/3D attributes in space as your listener
  • Your listener is within your event’s minimum distance, and is in very close proximity (proportional to the minimum distance) to the event - this can cause extremely minimal spatialization, in which case lowering the minimum distance can help

If your event doesn’t spatialize at all, even when a large distance away from the listener, and none of the above are occurring, could I get you to upload your Unity project to your user profile so I can take a look?

So it turned out it was a simple as to set a smaller sound size… :rofl:

The VR walkie never being further than the default 2m, the Listener was always to close and it was almost impossible to perceive the specialization.

In any case… thank you so much for the great support guys, as always.

1 Like

No problem, good to hear you were able to resolve the issue!

1 Like