I discover the line code “setPaused(false)” to stop and restart my music in same location after the game paused. Its works perfectly !
But every time the music restart, there are glitchs or numeric glitch and with a little delay.
This problem can be heard directly in FMOD and with any event.
Where does the problem come from ? It is possible to debug directly in FMOD ? Or Maybe in Unity ?
For the moment, we have cut in Unity the gain from bus music before the bug. But this creates a big delay (less 1 sec but it’s obvious)
I hope there is a solution.
Thanks for your response and thanks for this fabulous soft that respecte AUDIO in video game perfectly.
This is expected behavior. EventInstance::setPaused pauses/unpauses an event with a 64-sample ramp in/out, and Bus::setPaused uses no ramp, the latter of which especially can create clicks/pops. A very small delay is to be expected due to the asynchronous nature of the Studio System’s processing model, but this should be around 20ms-40ms, which is the default update rate, unless you’re using streamed assets. With streamed assets, from a brief test I was able to observe a delay of about 200ms with a streamed asset between the API command being enqueued, and the event’s output pausing/unpausing.
There’s a number of ways to make the pause/unpause less noticeable, and to work around the lack of a fade, both of which typically involves creating some means of fading the event volume yourself. A common one is to create a snapshot with an AHDSR that modulates the volume of the bus your event is routed to. In code, you can then start/stop the snapshot just before pausing/unpausing the event.
Just following up on this @sbdutoo - was my suggestion sufficient to work around the issue? If not, can you elaborate on any issues you were running into?
I read your answer which unfortunately does not give a solution for the delay but makes the clicks/glitchs invisible.
After various tests carried out with the tech of my project we found a solution which works perfectly !
This is to put setPitch(0) and setPitch(1) instead of setPause(true) and setPause(false). It works beautifully, without delay and glitches.
My apologies, I neglected to mention that the expected delay should be fairly low, around 20-40ms, which aligns with the default update rate of 20ms, unless you’re streaming the assets being played, in which case the delay can potentially be more significant, like the 200ms I noted. I’ve edited my initial post accordingly. If the assets you’re playing are set to stream, I would recommend disabling that in the Asset Browser, and seeing whether it makes a difference.
Otherwise, I’m happy to hear that you’ve managed to find a solution that works for you!
Yes I apply this method on music that is in streaming. Therefore, the delay is longer like 200ms as you say. Oui, j’ai trouvé une solution parfaite avec le pitch. N’hésitez pas à la partager.