ERR_OUTPUT_INIT on Windows, 2.02.05


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.

Previous topic:
How to best troubleshoot ERR_OUTPUT_INIT? - Unity - FMOD Forums

User info:
DxDiag.txt (88.6 KB)
Player.log (344.7 KB)

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, dated from 5/19/2016. Considering their age, I would recommend the user tries updating their drivers to a more recent version.

Thank you for taking a look at this.

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.

New user log and dxdiag:

DxDiag.txt (88.6 KB)
Player.log (344.7 KB)

The user updated the driver to the most recent Realtek one, but the problem persists.

DxDiag.txt (88.6 KB)
Player.log (344.7 KB)

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?

DxDiag.txt (25.5 KB)
Player.log (313.4 KB)

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.

Thank you for looking into this.

Heard back from one user and it’s as you suspected, disabling the AMD HDMI Output makes it initialize Ok and sound is working.

Second user confirms this, too.

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.

Thanks for your help tracking this down.

Hello, sorry to intrude on your discussion Talecrafter, I have a few questions for Mathew.

In which version exactly was this change introduced? Can you add this information to the known issue section please?

Was the fix integrated in 2.02.05 Patch 1 (06/02/22)?

The change in behavior was introduced in 2.01.13 and 2.02.04.

Added: Known issues 2.01.13 and 2.02.04

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.

Got a user confirmation that this is indeed fixed with 2.02.06, which is available now.

1 Like