Unity Mac Integration - I/O Error- Too many open fiies

Question

Hi you magical people.

We are experiencing issues on Mac with the Wwise Unity Integration after upgrading to 2019.3. See the errors in the screenshot.

- Unity 2019.3.3f1

- Wwise 2019.2.0.7216.1681

- Seperate git repositories for the Unity project and the Wwise project, both running Git LFS.

-macOS Mojave Version 10.14.6

- The project runs without any issues on Windows machines.

- I tested the same setup with a fresh Unity project, and a fresh integration, with 1 sound file. There it runs without any issue.

Any help from the braintrust is appreciated

https://imgur.com/a/BrwxWei

Comments

So creating an empty "Mac" folder as Waldek suggested got rid of some of the errors, so now they look like this: https://www.dropbox.com/s/s0cnl76lnlewieo/Wwise%20errors%20TSR.png?dl=0

"WwiseUnity: The platform SoundBank subfolder within the Wwise project could not be found.
UnityEngine.Debug:LogWarning(Object)"

We are building both Mac and Windows soundbanks from Wwise, so I don't understand why this is happening...

Any ideas? :)

---

Your latest set of errors implies that SoundBanks are not linked properly in Unity, hence events IDs are not found.

I'm ignoring the warning "WwiseUnity: The platform SoundBank subfolder within the Wwise project could not be found.", but.. I did attach my SoundBank manually using "AkBank" component to one of my scene's objects. Looks like it works :)

Answer 1

Hey Olmo,

* I believe you figured this out already, but here's the answer for anyone else with a similar problem.

I've asked around. If this doesn't happen when in a new project, the problem probably lies with your game project and not the Wwise integration.
I suggest seeking support from Unity, but for anyone else having the same problem, please us know if you find a solution to it.

Best of luck!

Answer 2

Hello,

I have the same problem (the same set of errors) on Unity 2019.3.0f6 and Wwise 2019.2, both on Mojave and Catalina (different machines).

What I can add to this is that my project stopped working after I've tried to reimport all the assets. The very same branch, but without Library/Temp/obj folders already built does not work.
So it looks like it's not a matter of codebase, but rather what's Unity doing while importing/caching assets.
I'm investigating this, because it blocks my project. I've tried deducing what's going on, removing things, but it only started working (i.e. assets import, without "too many open files" crash) when I removed Assets/Wwise.
So I believe it depends on what's inside Wwise project and whether all the assets are already imported.
I'll let you know when I figure out more.

Answer 3

I fixed my project by manually creating "Mac" folder in "Assets/StreamingAssets/Audio/GeneratedSoundBanks".
It looks like Wwise has been searching for it and Unity behaved very differently depending on its project's setup - adding Wwsie to an empty project, adding Wwise to the existing project or re-import of assets (e.g. platform switch).
In one case Unity catches an exception and logs it into console, in the other it crashes or hangs, reporting "too many open files", which is probably just an derivate set of bugs to some strange root cause.

Comments

Thank you for leading me to fixing this issue!

Struggled together with a team 1½ months ago with the same bug and eventually had to downgrade Wwise to 2019.1.x. Probably lost a week on this bug. Will file an official bug on this one, since it is due to Wwise.

Fix is, as stated, to create the Mac folder:
Assets/StreamingAssets/Audio/GeneratedSoundBanks/Mac/

What I did is to place an empty text file in there as well, to make sure git on Mac does not remove the folder again, like this:
Assets/StreamingAssets/Audio/GeneratedSoundBanks/Mac/EmptyTextFile.txt

---

Thank you for leading me to fixing my issue!

Answer 4

With:

* Unity 2019.3.9f1

* Wwise 2019.2.2

I just traced this issue, and discovered that it is originating from AkUtilities.UpdateSoundbanksDestinationFolders.

Within this function, you're attempting to load the Wwise .wproj file into an XML document. Loading our .wproj ends up throwing the "too many open files" exception.

I hypothesize that this isn't a problem with the game project per se, but is a problem introduced by using a complex .wproj (ie. a real project with a lot of units).

Answer 5

Hello all,

I managed to find a decent fix on our side and now everything appears to be working correctly as it was pre-upgrade. It's a small code change in AkWwiseXmlWatcher.cs. Details below:

• Unity: 2019.2.16f1
• Wwise version: 2019.2.2.7275
• Wwise integration: 2019.2.2.7275.1749
• macOS: Mojave 10.14.6

The constructor in AkWwiseXmlWatcher.cs starts a System.IO.FileSystemWatcher for xml files, and starts raising events before the path is set. When comparing the code pre and post upgrade, the older integration we had was setting the XmlWatcher.Path before setting XmlWatcher.EnableRaisingEvents to true, whereas the new one is doing it after. I don't know enough about the internals of how FileSystemWatcher works, so my hunch is that not setting a path starts a watcher on the whole filesystem(?) and therefore errors out with "too many files open" when trying to call AkBasePathGetter.GetPlatformBasePath(), which parse xmls to find the soundbank path. So the fix that worked for me is just to swap those two lines around so that they look like this:

XmlWatcher.Path = AkBasePathGetter.GetPlatformBasePath();

XmlWatcher.EnableRaisingEvents = true

After this change, everything seems to work smoothly for me again. Hope this helps someone els too! Maybe a question to Audiokinetic would be, was there a reason for that change? And have I inadvertently broken something else by doing it?

Cheers,

Manesh

Edit: Just want to confirm the steps I took to apply this.

1. Make sure working directory is clean (we use git for source control), and Unity is closed.
2. Upgrade the wwise project first and generate soundbanks.
3. Upgrade the Unity integration from the Wwise Launcher.
4. Modify the code in AkWwiseXmlWatcher.cs before opening Unity (this might not be 100% needed, but it's how I did it)
5. Finally open Unity and check that everything works. No extra directory creation or anything else needed.

Comments

Thanks a lot for sharing – very good to now if the problem returns!

---

Thanks very much! My Assembly Reload Time dropped from 16s to 4s!! Amazing.

---

Thanks man!! It works for me. I guess it`s a bug of .Net on Mac.
I have read the doc of FileSystemWatcher. It says that will not monitor anything until Path has been assigned a value and EnableRaisingEvents has to true.

---

Great !! Thanks