When using StudioListener.csin my games, I always drop it onto the Camera object which usually sits under the Rigidbody component of the player object. Form my personal experience, I found that this is the most common way to structure a “player” in Unity games. Additionally, it seems that this is the preferred way as Unity places it’s own listener component on the camera object.
To better illustrate the hierarchy I’m talking about:
Player (rigidbody, gameplay components)
|
+-- Head (camera, listener)
+-- HUD (UI)
+-- VFX (particles, etc)
+-- SFX (audio emitters related to player)
+-- Body (3D stuff)
Today an audio engineer from our team noted, that built-in parameters, such as distance were not working for spatial audio. I was confused initially as we we’re passing 3D parameters via RuntimeManager.AttachInstanceToGameObjectin our SFX. Then I looked into the code that ships with Unity FMOD and noticed that StudioListener.csuses gameObject.GetComponent<Rigidbody>()and does no additional checks to test if the listener is under a Rigidbody. Due to this, using the structure I showcased the listener does not attach to a Rigidbodyand the built-in parameters fail silently in FMOD.
My suggestion would be to use gameObject.GetComponentInParent<Rigidbody2D>() in StudioListener.csinstead of gameObject.GetComponent<Rigidbody>(). This way it’ll still work for users who place listener components on Rigidbodies as GetComponentInParent first checks the owning game object, but it’ll also cover the cases as I’ve shown. Alternatively private Rigidbody rigidBody; should be serialized to allow specifying it manually.