Hacker News Reader

Comment by userbinator | Hacker News Reader

A lossy codec that has only a single bitrate/quality? How does it compare to other lossy codecs in terms of audio quality?

All values, including the slices, are big endian.

In a world where LE basically won, that's an astonishingly stupid decision --- especially if you care about tiny differences in performance.

View on HN

I'm adapting QOA to the Dreamcast for streaming music. I've modified it to use 32-bit little endian values instead of 64-bit since (besides avoiding having to byteswap) the CPU in the Dreamcast is badly suited for 64-bit shifts.

For converting a "slice" from the 64-bit format (which is has a 4-bit value in the highest bits, and 20 3-bit values organized from high to low. Each 3-bit value is read from the high to low), I treated it as two separate 32-bit values. The bottom two bits of are combined to get the 4-bit value, and the rest contains two pairs of 10 3-bit values organized low to high.

So this:

  sample = (slice >> 57) & 0x7;  //Get sample
  slice <<= 3;  //Advance to next sample (64-bit shift)

Became this:

  sample = slice & 0x7;  //Get sample
  slice >>= 3;  //Advance to next sample (32-bit shift)

I think the conversion to 32-bit little endian was something like an 8-10% speed up, with no other changes? (This was a few months ago, and I didn't write down what the exact difference was.) The overhead big endian conversion and 64-bit shifts would become even more noticeable after further optimizations. (Replacing qoa_lms_predict with inline asm to use an integer multiply-accumulate instruction that GCC can't generate got something like another 20-25% speedup. Properly written asm would be even faster.)

BE is still common in very resource constrained applications like microcontrollers. You know, applications where having to do endianess swap actually has a significant impact? Applications where it might actually make sense to use this kind of codec?

I was really thankful that Doom WAD file was big endian (side effect of being developed on NeXT?) when I ported doom to an nRF microcontroller.

If you're exporting assets for a game, and the swap would be significant, shouldn't it really be generating big or little endian depending on the target? Many audio engines do this, using e.g. RIFX on big endian targets and RIFF on little.

I believe that in the case with Doom, and many other games that released there code as open source; the game assets are not in public domain and remain closed.

Isn't endianness either little or selectable on most (if not all) microcontrollers these days? For example https://infocenter.nordicsemi.com/pdf/nRF52832_PS_v1.3.pdf is little endian.

Considering that little endian is objectively better for more types of data structures than big endian is [1], one would expect things to eventually converge on little endian (barring the entrenched big endian network protocols that hold everything back). Building for the eventuality of little endian would make more sense in a modern format.

[1] https://www.technicalsourcery.net/posts/on-endianness/

I would argue Big Endian won in network protocols and file formats.

For network protocols, that's true only at the lower layers, and largely due to historical reasons.

The majority of file formats I've worked with are LE.

Reply on news.ycombinator.com