Hey folks! I’ve got a bug with FMOD (2.03.06) in conjunction with Dissonance in Unity 6000.0.37f1).
I’ve been speaking to @martindevans1 (developer of Dissonance) via email where he has identified:
Playback desync (XXXXms) AHEAD beyond recoverable threshold
When playback starts a timer is started. Every time the audio engine reads some audio another counter is advanced by however much time that audio represents. Desync is the difference between these two values. Obviously if the audio engine is reading audio at the correct rate they should always be in sync. “AHEAD” means that the audio engine has read more audio than it should have in the amount of elapsed time.
Buffer running dry! Offsetting sequence number back by 3
This means that 8 consecutive requests for more audio failed (because the input buffer was empty). We effectively rewind time a bit here, as a last-chance attempt to correct it.
Both of these things indicate to me that there’s something causing the audio engine to consume audio faster than real time. Since senders are only sending audio at real time rates would drain the buffer dry very rapidly.
Dissonance itself is not in control of the rate audio is consumed, it just provides audio when the audio engine requests it. So I think it’s most likely to be an external issue.
Is it possible you have some config in FMOD which is causing it to consume audio too quickly? For example a speed change or pitch shift effect?"
He suggested that I submit a forum thread on here to get support.
Any support is much appreciated.
1 Like
Hi, just chipping in with extra technical details of how Dissonance plays voice through FMOD.
We get the sample rate FMOD expects:
RuntimeManager.CoreSystem.getSoftwareFormat(out _sampleRate, out _, out _);
and then create a DSP:
var desc = new DSP_DESCRIPTION
{
numinputbuffers = 0,
numoutputbuffers = 1,
read = ReadDSP,
shouldiprocess = ShouldProcessDSP,
userdata = (IntPtr)_handle,
};
RuntimeManager.CoreSystem.createDSP(ref desc, out _dsp);
_busLock = FMODChannelGroupLocks.Instance.LockBus(OutputBusID);
RuntimeManager.CoreSystem.playDSP(_dsp, _busLock?.ChannelGroup ?? default, false, out _channel);
The ReadDSP function will pull audio from the pipeline. It removes it from the network buffer, decodes it, resamples it (to the rate discovered above) and provides it to FMOD.
The two errors that Mattabulous has both indicates that audio is being pulled from the pipeline too fast. In particular the Playback desync one is just comparing a timer (since playback started) with total_samples_consumed * sample_rate, obviously those should stay in sync, but they get out of sync very rapidly!
My best guesses are that it’s either:
- A bug in my playback code that no one else has encountered.
- Something unusual in the way Mattabulous has set things up in FMOD. But I don’t know FMOD well enough to guess what it could be.
Hi,
Thank you for all the information!
- Has the default sample rate been changed in the FMOD Settings:
- Are there any issues when playing other FMOD sounds?
- Could we confirm the
_sampleRate the plugin is getting by adding a log after RuntimeManager.CoreSystem.getSoftwareFormat(out _sampleRate, out _, out _);
- Could we add some logging to the
ShouldProcessDSP
- Time
- Sample rate
- buffer size
- Num channles
1 Like
Turns out the sample rate had been changed. Changing this has fixed it right up.
Thanks a lot @Connor_FMOD and @martindevans1!
2 Likes
Good to hear it’s solved! Please do not hesitate to reach out if we can assist with anything else!
Hey guys. I’m getting the same error but setting the sampling rate to platform default did not fix it for me 
I have logged the sampling rate, along with the requested information in the ShouldProcessDSP callback. Let me know if there is any other information I can provide to help diagnose the issue.
To add on to this, we’ve just built the game and have the same issue again. Will send logs when I’m able, if that’d be of help.
1 Like
Hi,
Thank you for the information. Could I please grab your FMOD and Unity versions? Would it be possible to test a couple samples rates and let me know if you see any improvements?
Was the sample rate set for the Editor or the Default platform:
Could we try adding the platform settings to make sure we are getting the sample rate we expect:
With the following settings:
And the logging we mentioned before, can you please share the logs?
FMOD version is 2.03.07
Unity version is 6000.0.44f1
I tried all the sample rates in the sample rate dropdown for the Editor platform. I can reproduce the issue with all of them. I did notice that with 48 kHz, I was not able to reproduce the issue during one test and had to test again. I am testing locally on the same machine with 2 game clients (same microphone). So the issue is not 100% reproducible but fairly easy to reproduce.
1 Like
Thank you for testing that. Would it be possible to upload the Unity project and any built FMOD banks to your profile for me to test?
Steps to reproduce the issue would be awesome too!
Update - We realized that FMOD was Virtualizing the player voice playback. We changed the fmod events for the player voices to ensure they don’t get virtualized and voice seems to be working fine for now. Will keep everyone updated if anything changes. Apologies for not noticing this earlier.
1 Like
Thank you for sharing the solution. @Mattabulous would it be possible to test this as well?
Seems to have fixed it, yep. Going to do another playtest with 2 remote players and see if it’s still working before marking as a solution 
I changed the settings for the Voice Bus to this. Turning Stealing off turns off virtualisation (had to put Max Instances to 64 rather than infinite to edit this setting). Not sure there’s another way to do this?
1 Like
After some further testing, it’s seemed to have come back up but only on the client when listening to host. Not really sure what has caused it to do that…
Is there any way to add you to the GitHub repo temporarily as opposed to linking it through FMOD Projects?
EDIT: Further testing has revealed it continues to show up – doesn’t matter if it’s client or host. Seemingly no way to reproduce still.
Thank you for testing that.
You can use the FMOD Studio | Event Macro Controls Reference - Priority macro to stop an event being vertualized. If an even is set to the Highest priority it will never virtualize. Could you please try that?
You could add Connor-FMOD as a collaborator which would give me access to the repo.
Sadly, Dissonance passes it via a bus channel so can’t use an Event Macro.
I’ve just added you as a read-only collaborator to our git repo @Connor_FMOD.
Please use the branch “FMOD-Voice-Chat” – Let me know if you need anything from me.
1 Like
Thanks for adding me, I am currently exploring the project.
Would it be possible to test calling FMOD Engine | Studio Api Bus - Studio::Bus ::Lockchannelgroup on the dissonance bus. This will force the channel group to stay available. Let me know if that helps!
Looking through Dissonance’s code, seems like that’s already done:
Thank you for testing that.
Could I get some reproduction steps for reproducing the issue?
