We’re developing a VR game for quest and are using resonance audio. I’m starting to find the inability to use mixer snapshots super frustrating. I’ve floated the idea of using a mix of resonance audio events and FMOD spatializer events. However our dev’s worry about the cpu load that may accrue as we’re building primarily for quest which might negate the use of resonance.
Does anyone have any mixer work arounds using global parameters for mixing, or any experience using both the FMOD spatializer and Resonance Audio.
As far as we’re aware, the Oculus Quest has no special support for Resonance Audio that would make the Resonance Audio effects more CPU-efficient than FMOD’s spatializer effects are. Using a mix of spatializer effects and Resonance Audio effects should therefore require less CPU load than using only Resonance Audio effects, not more.
Using the spatializer effect in some events and the Resonance Audio plugins in other events of an FMOD Studio project is not too difficult.
For it to work, the Resonance Audio Listener effect must not be in the routing path of any event that doesn’t use a Resonance Audio Source or Resonance Audio Soundfield effect. This is because the Resonance Audio Listener effect replaces the signal at its position with a mix of the signals it receives from Resonance Audio Soundfield and Source effects, meaning that other events’ signals that route into the same bus as the Listener effect will not be audible in the final mix. To work around this limitation, put the Resonance Audio Listener effect on a group bus that routes into the master bus, and do not route any events that do not use a Resonance Audio effect into this bus.
You should route all events that do use the Resonance Audio effects into the bus containing the Resonance Audio Listener effect. FMOD automatically optimizes away buses into which no playing events are routed, so if you don’t route all your Resonance Audio-using events into the group bus containing the Resonance Audio Listener, the bus may be optimized away while Resonance Audio-using events are playing, resulting in those events being inaudible.
I’ll have to double check with our dev. They seem to think that resonance audio counts voices in a way that is more efficient? Since there is only one reso listener it doesnt see additional voices as additional CPU load. But i may be totally, Im trying to remember their explanation
I’m currently developing for a Quest game as well and made the decision at the beginning to go with Oculus Spatializer, exactly for this reason, and so that there’s a higher chance of compatibility and performance and helpful user support with using software made by the hardware developer.
This is probably not the advice you want to hear but it may not be the worst thing to spend the time to replace Resonance with Oculus Spatializer. Can’t imagine mixing a game without the ability to use snapshots. I did this once for a VR game — was using another spatializer which sounded much better than Oculus Spatializer but wasn’t working for us in other ways, swapped it out for Oculus and didn’t look back.
If it’s not possible to switch, you could definitely set up a global parameter system to control groups of events. Make a plugin preset with a gain plugin, title the preset to whatever you’d name the mixer bus, use that preset before Resonance in the chain on all events you want in that “bus”. You could even drive that parameter with an event that can function similar to a mixer snapshot, the main caveat being no ability to blend snapshots: automate the global param, looping region to sustain the event, “stopping” condition on a transition region on top of that loop, destination marker with a fade out of the parameter.
I see why they’d think like this, resonance audio uses an ambisonics encoder and decoder, which I also thought makes little difference wether using just one or one hundred sound sources. In practice one hundred sources still ended up being too much for the Quest but i guess that’s not necessarily related to the spatializers themselves but perhaps the processing happening in the multitudes of events. You could of course, if you have the time, do a profiler cpu test with both scenario’s of using just either spatializer to see which one is more kind to the Quest.
Eventually we also went for a mix of both spatializers, to calm the cpu and had to find out how this could work, like Joseph is sharing here, the hard way. We used resonance on only those sources that needed exceptional spatial localisation.
Because of this ambisonics’ specific and very rigid signal flow, sacrificing mixing flexibility is quite bummer indeed, but for what it’s worth: you can still lower the entire ambisonics decoder output independently from the other sounds, and I guess that is still controllable with snapshots, no?
Good luck either way!
This is not the case. Voices are created by event instances, but neither the spatializer effect nor the Resonance effects interact with voices directly; instead, they interact with the submix of content created by each track and bus in your project. As such, your choice of spatializing effect has no effect on the number of voices used by your project.
Thanks for clearing up that misconception! So voice count doesn’t change, that makes sense. But if you’d have 1000 events, each playing one voice simultaneaously, would it be safe to say the encoding ambisonics for each voice and the decoding at the (sub-)master to, let’s say binaural, is more more cpu heavy than when one would replace all of the 1st order ambisonics with the spatializer plugin?
The Resonance Audio plug-in effects internally operate by using third-order ambisonics. In third-order ambisonics, encoding is cheap, but decoding is expensive; and encoding needs to be performed once per voice, but decoding only needs to be performed once on the submix of all encoded voices. (You could also think of the Resonance Audio Source and Resonance Audio Soundfield effects as being cheap, but the Resonance Audio Listener effect as being very expensive). This means that using Resonance Audio for spatialization has a high fixed cost, but can scale to large numbers of voices without much additional cost. The FMOD Spatializer, by comparison, has a fixed cost per signal it affects, but is far cheaper than a Resonance Audio listener, even when used in many different events.
This means that, in theory, there is a point at which the number of voices is high enough that the Resonance Audio plugin becomes cheaper than the FMOD Spatializer. In practice, you won’t reach that point, as the number of voices required is simply too high.
In fact, you’ll never even approach that number. The 1000 real voices suggested in your hypothetical situation is far more than most platforms’ hardware can handle, regardless of spatialization method. To prevent this, FMOD’s virtual voice system automatically virtualizes voices in excess of the number specified via System::setSoftwareChannels. This number is usually only two digits, and is 64 by default. As such, if your game is playing 1000 voices, ~936 of them won’t actually produce any audio to be mixed, and so will not actually require any CPU time to spatialize.
At the voice counts that can actually happen, the FMOD spatializer will be cheaper than the Resonance Audio plug-in effects.
All that being said: If you are concerned about the resource costs of various options, the best option is always to test them using your project, as this will provide the most accurate possible information about those options’ performance in the specific condition you need them for.
but i guess that’s not necessarily related to the spatializers themselves but perhaps the processing happening in the multitudes of events. You could of course, if you have the time, do a profiler cpu test with both scenario’s of using just either spatializer to see which one is more kind to the Quest.