In our game we have 1 audio file that does not want to compress like all the other files.
All files are OGG format on disk, and all have the exact same import settings. As do all other audio effects in the game.
Yet somehow, this one audio sample, across two entirely separate projects. One project was not derived from the other, they just happened to use the same .ogg source file. It refuses to compress and instead becomes 1MB in memory regardless of compression quality used.
All files are similar in size, length, and even content is the same. They are just slight variations on the same audio. Additionally, we have opened the file in Audacity, cut off a tiny sliver of audio, re-saved the ogg file as a new file on disk, and then put it in again. It still causes the exact same behavior.
What could be going on here? What could cause this behavior for only 1 file, across multiple projects?
Unity versions 2021.3.18, 2021.3.28 and 2020.3.41
Hi @Vince-Chimp this is currently in our bug queue, we’ll be investigating it and will update you when we get there. We think it might be linked to some “sandbox” memory we setup early on but why it would stick to your asset is still a mystery.
Is there anything i can do on my end to try and “cleanse” my asset beyond what i already did and described above?
Would it help if i went you the file in question?
I have no problem doing so, as long as it’s not put in a public space as the project is under NDA and i can’t just go tossing assets around to strangers online.
I can’t think of something (safe or sane) right away… I don’t recommend doing a binary surgery on the file, as some asset management metadata or code might remember this 1.0MB value and break things during the serialization/deserialization process.
I think it’s only a matter of patience now. A colleague already looked at this and did a repro. We do have a heavy backlog, but I’m confident this issue will be addressed soon enough. I can’t provide an ETA though…
It is not a blocker, but we are definitely working on minimizing RAM use as part of reducing ANR’s on Android. And this just seemed off. We definitely have bigger fish to fry though.
I am amazed you managed a reproduction on your end with no other specific details from my end. Good to hear, i will keep an eye out for this getting resolved. Thanks for the information!
So apparently, this issue was deprioritized closed as “Won’t fix”. From what I understand of the notes, this memory is used by the codec as a kind of sandbox buffer, but somehow gets associated to a file in the profiler perspective.
I suspect this memory is always allocated, and I don’t think it’s harmful. I’m sorry that it leads to a misleading memory analysis though…
The reason why it won’t be fix is likely because the issue is about how the asset-audio-profiler systems interact, and the investment into the investigation and fix would be disproportionate to the benefit of solving it.
I understand that’s probably not the answer you were looking for, and certainly not the one I wished to bring, but at least that’s the truth.
Actually, that is all i need to know. If this is how it works, and it is just random chance to which file this gets attributed, that is good information to have. I would suggest documenting this somewhere so others don’t have to be as confused as i was, especially if there is a “won’t fix” resolution. But otherwise that is all good with me.
Thanks for checking for me, i can now write this off of my checklist as well!
