Every time we load an audio clip from disk using WWW.GetAudioClip (in this case an mp3) and set it to stream, Unity will constantly leak memory. It’s pretty significant as well (about 1-2mb/minute).
If you don’t stream the audio clip, it does not leak. Unfortunately for us this poses a problem as loading an mp3 without streaming adds quite a bit to memory, I’m assuming because it gets decompressed. Because of cross fading several tracks (we have bg music + ambient music) we can have up to 4 mp3s loaded at any given time. Not only is our memory up by 20mb because we have the entire uncompressed mp3 in memory, but during a crossfade the memory can spike by 20mb+
This is in Unity 5.2.1f1. This did not appear to happen in 5.1.3p1 and it only appears to happen on iOS, did not appear to happen on Android.
I’ve created a bug with a test project, here’s the ticket: 733097_2revdvfhitapmuo2
I’ve tried loading the AudioClip (with streaming on) using Resources.Load and it does not leak. We would prefer to not do this, as we’re already pressed for space on iOS (trying to stay under 100mb…), but it’s a workaround for now.
technically it’s not a memory leak:
the iOS implementation appends all the incoming data to a buffer while the connection lasts; - and it gets cleared when connection is closed - you can test this by e.g. disposing the WWW var - you will see memory usage drop in Xcode.
so it’s not technically a memory leak, but the buffer usage gets so big over time when streaming potentially endless stream that the OS inevitably kills the process after some time
I’ve reported similar bug report just a few days ago: #732371
the generated Xcode project has this part of NSURLConnection implementation the same in 4.x and 5.x - so I’m not entirely sure why you did not see it in 5.1.3p1 - might be different problem
