4 ms·

> which will be LE on every PC and phone that would ever run this Why would you want to run this on a modern high end PC or phone? There's almost no point usin

by audunw 4y ago

> which will be LE on every PC and phone that would ever run this Why would you want to run this on a modern high end PC or phone? There's almost no point using a simple codec like this if you have the computing resources or dedicates hardware to use a "proper" codec. The codec is probably a reasonable choice for a microcontroller where you do want to save memory but you barely have CPU cycles to process the audio data. Many microcontrollers are big endian.

makapuf 4y ago
Sure there is lore diversity in microcontrollers and there are bog endians but much more are or can ne configured as little endian ARM, riscv, avr, mips, msp430 ..
flohofwoe 4y ago
For cross-platform 'gamey code' (e.g. game jam stuff or smaller indie games), having an audio file format which is very simple to load and decode in your own code without having to use the plethora of platform-specific audio decoder APIs, or having to integrate decoder libraries with often questionable API design choices (which is often a challenge of its own) has a lot of advantages. Same arguments for using the Quite OK Image Format over things like PNG or JPEG for instance (although since stb_image.h this isn't such a big issue anymore).
electroly 4y ago
Your post: "Why would you want to run this on a modern high end PC or phone?" Another post in the same thread: "In the real world, for this type of code ..., only a very small number of CPUs (Intel and ARM) and C compilers (Clang, GCC and MSVC) matter ..." These posts are strongly disagreeing with each other but neither of you directly replied to the other, so I'm not sure if you've seen it. I'm replying to you because I think, between the two of you, you're the one that's wrong and the other poster is right. The original announcement doesn't mention microcontrollers at all and does mention computer games[1]. Further, their defense for the endianness decision was simply that they like it, rather than that they expect any target CPU to be big endian. I think GP is right--this will almost never be run on a big endian CPU. Indeed, the start of this thread was a piece of code that won't work at all on smaller microcontrollers. I think it's likely this code has never been run on a microcontroller. [1] https://phoboslab.org/log/2023/02/qoa-time-domain-audio-compression https://phoboslab.org/log/2023/02/qoa-time-domain-audio-comp...

by audunw 4y ago

makapuf 4y ago

Sure there is lore diversity in microcontrollers and there are bog endians but much more are or can ne configured as little endian ARM, riscv, avr, mips, msp430 ..

flohofwoe 4y ago

For cross-platform 'gamey code' (e.g. game jam stuff or smaller indie games), having an audio file format which is very simple to load and decode in your own code without having to use the plethora of platform-specific audio decoder APIs, or having to integrate decoder libraries with often questionable API design choices (which is often a challenge of its own) has a lot of advantages. Same arguments for using the Quite OK Image Format over things like PNG or JPEG for instance (although since stb_image.h this isn't such a big issue anymore).

electroly 4y ago

Your post: "Why would you want to run this on a modern high end PC or phone?" Another post in the same thread: "In the real world, for this type of code ..., only a very small number of CPUs (Intel and ARM) and C compilers (Clang, GCC and MSVC) matter ..." These posts are strongly disagreeing with each other but neither of you directly replied to the other, so I'm not sure if you've seen it. I'm replying to you because I think, between the two of you, you're the one that's wrong and the other poster is right. The original announcement doesn't mention microcontrollers at all and does mention computer games[1]. Further, their defense for the endianness decision was simply that they like it, rather than that they expect any target CPU to be big endian. I think GP is right--this will almost never be run on a big endian CPU. Indeed, the start of this thread was a piece of code that won't work at all on smaller microcontrollers. I think it's likely this code has never been run on a microcontroller. [1] https://phoboslab.org/log/2023/02/qoa-time-domain-audio-compression https://phoboslab.org/log/2023/02/qoa-time-domain-audio-comp...