Especially his conclusion that “it’s fine”. I’m sure, I was just remarking that his comment here was not useful in any way.
I BELIEVE I CAN FLY.WAV CODE
He has helped this project immensely over several years, and our 3D code basically depends on him. Please remember, you are using tools built by volunteers in their spare time, and is such a volunteer. 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. If mgsx-dev also provided the speed for wavs we’d probably see the same problem. That conclusion could be reached on any hardware. I don’t think a game that only works on M1 macs would be particularly useful so not sure what this would prove? Also my test shows the difference between wav and ogg is too great. Strangely you’re yet to ask mgsx-dev at all, despite the fact he didn’t even provide the OS used, never mind anything else. I feel like asking repeatedly is a waste of my time. 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 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. I could easily enough change any of the above, but I don’t see what for. So that this argument has one fewer direction to head in, my relevant specs are:Īn SSD that’s bottlenecked by being connected over SATA (note: tested audio may have been cached in memory from previous reads) 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.įrosty-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. He didn’t say anything about a game only working on one or the other. I don’t think a game that only works on M1 macs would be particularly useful so not sure what this would prove? 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.
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. x86-64 difference is actually quite significant, and you could quite reasonably be running either in 2021. I would rather not waste my time! The AARCH64 vs. 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. While I’m not surprised the compressed formats take longer, being ~3× slower suggests something suboptimal is going on here in libGDX land. Some of the above codecs can be used on mobile and web, and I hope will be supported on desktop one day. Tested on libGDX 1.10.0 with Java 11 and LWJG元. 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.Īll test files are 128kbps (☑kbps) with the exception of HE-AAC (64kbps) and of course (AD)PCM and FLAC. 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. This isn’t super scientific, but I’ve tested the decode times of various codecs on my computer with ffmpeg. 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.
0 kommentar(er)
