We can reproduce the issue by inserting both user-uploaded audio and Roblox-uploaded audio with similar length and check its memory usage in developer console
Reference from repro baseplate - 12594339213 is user-uploaded audio clip and 1848354536 is Roblox-uploaded music audio
When playing an audio asset, there is a tradeoff between CPU and memory usage; the best thing for CPU time would be for all audio assets to be kept uncompressed, in-memory.
However, this is probably not a good idea generally, since uncompressed audio (such as .wav) can get pretty large.
Streaming audio assets from disk can use substantially less memory – but this uses more CPU, and depends on IO speeds.
Another consideration is that many Sounds can play the same asset at the same time, but possibly with different TimePosition values at any given time. If all assets were in-memory, duplicate Sounds could share a reference to the same asset, even if their TimePositions differ. However, if all assets were streamed from disk, each Sound would have to stream in a region of audio data around its TimePosition – in highly-duplicated scenarios, this can end up being even more memory than if we naively prioritized CPU!
The engine tries to weigh these considerations automatically, and make a decision based on context – it’s not perfect, but that could explain the disparity you are seeing. Generally: large, long assets will be streamed, whereas small assets might get decompressed directly into memory.
Yes.
Also, how are finding the audio file memory usage. I went looking through mine and couldn’t find anything audio related. I was looking under Client / Memory usage, should I be looking elsewhere?
