libgdx: Ogg files load way more slowly than wav files

I feel like I’ve been to Hell and back, figuring out Unity. Think I’ve managed to conjure up an equivalent test - loading an AudioClip from outside the project (libGDX test was also external). I think it might be possible to shave off ~50ms from this, but you get the picture. Here’s the current score on the three:

Format	libGDX	ffmpeg	Unity
16-bit WAV PCM	779	752	764
MP3	12196	3224	5717
OGG Vorbis	9745	3493	5593

libGDX is still the loser, but you need to be loading in an awful lot of audio in one go on desktop for it to really matter.

Oh, hey, entitlement city! So, first of all. As Nate sad, the decoders for both OGG and MP3 are pure Java decoders. That means they will be slow until the hot code paths have been run a few thousand times until the JIT compiler of the JVM kicks in. No mystery, conspiracy, etc.

What could be done:

• Improve performance of the existing pure Java decoders. Unlikely to be fun or worthwhile.
• Use LWJGL 3’s stb vorbis wrapper. Then decoding happens in native code from the first invocation: https://javadoc.lwjgl.org/org/lwjgl/stb/STBVorbis.html

And since libGDX is such a nice open-source project, you can totally send a PR that swaps out the Java decoder for OGG for the stb vorbis decoder in LWJGL 3 instead of telling people actually contributing code to and maintaining libgdx that their comments are useless.

I wanted to see if there’s anything more behind this issue, and I kind of lost track of what direction I was going in with this comment.

Tests

This isn’t super scientific, but I’ve tested the decode times of various codecs on my computer with ffmpeg. While blatantly ignoring the fact sound effects will be lots of small files (which will be slower than loading one large file) it gives us an idea for what kind of difference is realistic.

The source file used was the 2010 remaster of Supertramp’s Breakfast in America album, ripped from CD - 46m19s in length, and unsurprisingly 16-bit stereo 44.1kHz.

All test files are 128kbps (±1kbps) with the exception of HE-AAC (64kbps) and of course (AD)PCM and FLAC. Three tests for each. Time is in milliseconds.

ffmpeg: libGDX-supported codecs

Format	1	2	3	Avg.
WAV 16-bit PCM	750	755	750	752
MP3	3289	3189	3195	3224
OGG Vorbis	3533	3443	3504	3493

libGDX: libGDX-supported codecs

Format	1	2	3	Avg.
WAV 16-bit PCM	785	776	777	779
MP3	12194	12270	12124	12196
OGG Vorbis	9838	9728	9669	9745

Tested on libGDX 1.10.0 with Java 11 and LWJGL3.

ffmpeg: Other codecs

Format	1	2	3	Avg.
WAV 8-bit PCM	555	563	575	564
FLAC (multithreaded)	903	923	911	912
WAV IMA ADPCM	1288	1250	1274	1270
AAC-LC	2332	2312	2323	2322
MP2	3307	3319	3278	3301
FLAC (single-thread)	3658	3640	3661	3653
HE-AAC	4387	4399	4394	4393
OGG Opus	7728	7706	7702	7712

Some of the above codecs can be used on mobile and web, and I hope will be supported on desktop one day. But the table’s partly a digression.

Conclusion

While I’m not surprised the compressed formats take longer, being ~3× slower suggests something suboptimal is going on here in libGDX land.

If I were in charge, I’d have been likely to close this issue with the reasoning of “of course OGGs load more slowly than WAVs”, but now I’m thinking this raises the point that libGDX’s desktop audio decoding speed could be improved upon, so it could be worth leaving open for that alone.

I tested with my game and i can load 351 ogg files (total 3MB on SSD) in 1500ms which is totally OK for me considering that :

• i only use one thread to load them (that could be an improvement for your case)
• most of my other assets are way much heavy (3D models, textures, etc…).
• i loaded them all at once (in real life, you typically only load needed assets before a level)

So i would say that OGG is totally fine for most use cases. If loading time is much more important to you than storage (i can understand that), then WAV format is better.

MP3 is another story, it has some huge drawback (padding making them not perfectly loopable, etc)

Haha, you actually did a Unity test, you mad man! Cool to see the numbers.

libgdx uses OggInputStream by Kevin Glass which was used in an old Java game toolkit called Slick (ah the memories). It uses the JOrbis library. I vaguely remember hacking on OggInputStream long ago to make it a little more efficient. If it’s JOrbis that is slow, it’s a bigger issue.

MP3 uses javazoom. I’m not surprised that is slow. MP3 decoding in general seems like quite a mess. I would avoid it if possible and use OGG.

I don’t think a game that only works on M1 macs would be particularly useful so not sure what this would prove?

He didn’t say anything about a game only working on one or the other. libGDX games can run on both Intel and M1 on macOS (albeit more prone to technical issues on M1 until we no longer need Rosetta) so we wouldn’t be able to figure out which you’re using on our own.

Frosty-J doesn’t appear to have provided the system or hardware used either but I feel the information he gave is valid since it’s a comparison.

So that this argument has one fewer direction to head in, my relevant specs are:

CPU	Intel i7-4770
RAM	Dual channel DDR3 1600MHz, mixed brands
Storage	An SSD that’s bottlenecked by being connected over SATA (note: tested audio may have been cached in memory from previous reads)
OS	Ubuntu 20.04

I could easily enough change any of the above, but I don’t see what for. I expect WAV to always be faster, and typically by a similar percentage, except in the case of slow storage such as loading from floppy disk.

You still haven’t provided any basic info on your hardware (such as “year built” or “Intel processor” or “a new M1 Mac”) other than “MacOS”. I feel like asking repeatedly is a waste of my time. I would rather not waste my time! The AARCH64 vs. x86-64 difference is actually quite significant, and you could quite reasonably be running either in 2021. It’s entirely possible that this issue doesn’t appear on M1 Macs, but does on Intel, or vice versa; it’s even more likely that the magnitude of severity is different on different architectures, OSes, eras of production, etc.

Please remember, you are using tools built by volunteers in their spare time, and @mgsx-dev is such a volunteer. He has helped this project immensely over several years, and our 3D code basically depends on him. He’s earned our respect. @Frosty-J has recently contributed some really in-depth reporting on various issues that would have otherwise stagnated, and he’s shown a keen eye for detail. He’s also earned our respect.

I tested with my game and i can load 351 ogg files (total 3MB on SSD) in 1500ms which is totally OK for me.

You can only ever compare it with how long it takes with other engines and with how long WAV takes to load on LibGDX, which you strangely didn’t mention. Saying it’s ok for you on a fast desktop with SSD is pretty useless information since there’s different desktop systems/hard drives and even mobile systems where file size will be even more important and it will be even slower…

Frosty-J’s tests were infinitely more useful. You could at least add the time for loading them in wav format and the size of the oggs since I loaded only 49 in about the same time. I also use an SSD so we can expect slower times on a normal hard drive.

Music: Streams the file from disk while it plays. A good fit for long things such as music and ambience. Sound: Decodes the entire audio file into memory at once. So it’ll take longer to load but can be played immediately once loaded without the latency of having to access storage and decode the file. The obvious choice for short sound effects such as attack sounds. Not really weird.