We have a user with an ERR_OUTPUT_INIT who sent us their log and dxdiag file. API error logging is enabled, but I personally can’t identify the cause.
According to the user they tried disabling the “allow exclusive mode” setting in the Windows config to no avail, and according to them other FMOD games work on their system.
They would be willing to help us with more testing, if it’s helpful.
I made a previous topic about the general troubleshooting on ERR_OUTPUT_INIT but I thought it’s more useful to have a specific topic for this specific case.
The internal error is IAudioClient::GetMixFormat() which is a Windows API that tells us what audio format the system is running. It’s returning AUDCLNT_E_UNSUPPORTED_FORMAT which doesn’t make sense, the “mix” format is the one format that is always supported and that function should never return that error. We need this information to initialize FMOD so I don’t see an obvious workaround.
A quick Google yields some bug reports here and here that Microsoft acknowledged but no further info was given. Generally this kind of thing relates to buggy drivers and not a core Microsoft issue.
Based on the dxdiag, I can see the primary output device is “Realtek High Definition Audio” with a driver version of 6.0.1.7829, dated from 5/19/2016. Considering their age, I would recommend the user tries updating their drivers to a more recent version.
The user updated their driver to a 2020 version, but the error persists.
Has this GetMixFormat been used by FMOD in previous versions in a similar way? The user mentioned that they had played other games using FMOD fine on that system.
This is probably totally unrelated, but we’re using the IL2CPP export of Unity and not Mono. Just mentioning this as it might be where our game differs from other Unity games.
I have another user with the same problem. I’m attaching their data.
More importantly however, since the user mentioned having played the game with sound before, I provided an older version of the game to both and both confirmed having sound with that older game version.
We were using FMOD 2.01.07 on that older game version.
Since both persons are testing it on the same system, we can rule out Windows updates or driver changes now, I guess.
I could try to narrow it down (apart from the FMOD update, there were also changes on our code side in what order systems get initialized etc., so there might be a chance it’s influenced by that) but if you have an idea where to look or how to test for it, that might save me some time. Did 2.02 for example bring changes to the init process?
There was a recent patch that changed the behavior of IAudioClient that would explain the difference between 2.01.07 and 2.02.05 you are seeing. If the issue is what I suspect, then I recommend getting the user to disable all audio devices expect the one they intend to use. According to the dxdiag, both users have additional audio devices (DELL S2721DGF and AMD HDMI Output).
In our patch we query all audio devices at init time, if they give errors it is fatal. Getting errors from this function is very surprising, but it shouldn’t be fatal, especially if the device causing the errors isn’t being used. I can fix this (if this is the issue), if disabling the additional devices works for your users, that will be the proof I need.
Excellent, that’s good news. So this means updating the primary audio drivers wouldn’t help because the device that had the issue was one of the non-default devices I listed in the previous post. Perhaps updating the drivers for the other devices would help, regardless a faulty driver for a device you aren’t playing audio on shouldn’t be a fatal condition. I will get this fixed to keep the fail behavior similar to 2.01 in which it’s only fatal if you choose to play on the faulty device.
No, the patch1 release was an emergency fix for a single critical issue.
The issue discussed in this thread is fixed in the upcoming 2.01.15 and 2.02.06 releases.