Ogg files load way more slowly than wav files

Issue details

The only change I make is to switch my sound effect folder all to .ogg rather than .wav and the load time difference is:

All wav sounds: assets 229 screen 441

All ogg sounds: assets 1548 screen 1749

The difference in loading time is somewhat noticeable anyway, but I’ve provided the actual times for clarity.

Reproduction steps/code

Load sound effects as ordinary Sound files as wav and then all as ogg and test the loading time of each.

Version of libGDX and/or relevant dependencies

1.10.0

Please select the affected platforms

• MacOS

[Frosty-J]

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.

[badlogic]

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.