I’m trying to get some clarification on what is considered a “large” audio file in GDevelop. The audio documentation only states to use “Play Music” for “large audio files” but doesn’t specify a file size, time limit, or bit rate.
In our game, “Play Sound” works great to loop music in the background. The background audio files are .mp3s and are rarely larger than 5MB. To me, this isn’t a “large” audio file, but I have no reference to know if that is correct.
Can anyone point me to further documentation, or clarify what the threshold between a “small” audio file and a “large” audio file is?
Ok…I’m not sure if that’s actually the answer I’m looking for though…The “Play Sound” and “Play Music” functions are clearly separated in the GDevelop documentation and I’m looking for the size or time threshold for each use…Also, I’m not sure that 15MB limit is correct?
If play music vs play sound is what you’re looking for, perhaps this post might help:
As for large or small, I suppose anything 1mb or larger may currently be considered “large”. But that’s just my own estimate, considering that most sound effects are usually less than 1mb.
Yeah, I don’t think there are any “official” or standard rule as to which file sizes are to be classified as large or small. Like maybe future tech and innovations are being put into consideration. Back in the day 16mb ram was super. Yet now, 4gb ram is perceived to be utterly small. lol
It is in the documentation, just gotta read down the page a bit:
Short audio files, like sounds effects, can be played using the Play a Sound actions. It’s adapted to short sound effects because they will be fully loaded in memory before being played.
Large audio files and background musics must be played using the Play a Music. It works better with large audio files as it streams the audio in memory - resulting in less memory usage. The drawback is that musics needs to be decoded and streamed on the fly, resulting in a few milliseconds latency when you play the music for the first time.
Preloading an audio file as a sound effect or as a music can help to reduce the latency the first time a music (or a sound effect) is played. See the next sections.
I’ve had trouble in the past getting music to loop properly and used the sound action instead as a workaround. It just means more memory usage, which I didn’t mind for my particular case since the files were small anyway. And it was a “just get it done” move. There was some discussion about it and I think I remember some people getting music to loop perfectly using the music action, so that is probably the best solution especially if you have very large music files. There isn’t a hard limit.
Thanks. I’ve already read through the documentation which doesn’t state a threshold, it just simply defines “short” and “large” audio files without a specific file size or duration limit.
“Play a Sound” works perfectly for looping since it loads directly into memory instead of streaming like “Play a Music” which does not loop properly since it’s streaming.
I’m trying to understand the threshold at which “Play a Sound” needs to be changed to “Play a Music” since there may be memory usage issues with very large files and then stay under that threshold with the audio files so we don’t need to use “Play a Music”.
I’m trying to convince my devs that “Play a Sound” for a 1MB - 2MB music loop is perfectly acceptable as it isn’t going to crash any of the lower-end hardware of our players during decompression.
Yeah, I think we all know it will be fine, but I need some hard metrics to confirm and convince them that we’re not going to break anything with this method.
Again, there isn’t a hard metric, because it depends on the device. Just find a crappy phone to run your game on, see what happens. You aren’t going to break anything by using too much memory, worst case scenario is a crash but most likely you’ll just slow down the device. A few megabytes is nothing for today’s devices, so your devs should be able to sleep at night
We’re on the same page with that…Unfortunately, I think they’re either too lazy to test it or just afraid if something DOES break, they’re the ones to blame. It’s a lucrative app and the last thing they want is to lose revenue and for heads to come flying off.