Opus output is written in host byte order but consumed as little-endian PCM

[mguaylam]

Read-confirmed, not reproduced — saying so up front, because the two sibling defects below were reproduced and this one was not.

SendspinDecoder::decode() in src/decoder.cpp hands libopus the output buffer through a native-width cast:

int output_frames = opus_decode(
    this->opus_decoder_buf_.as<OpusDecoder>(), data, data_size, (int16_t*)output_buffer,
    this->current_stream_info_.bytes_to_frames(output_buffer_size), 0);

opus_decode() writes opus_int16 in the host's byte order — that is its documented contract, not an inference. The buffer it fills is then consumed as little-endian PCM: a host sink opens SND_PCM_FORMAT_S16_LE, and the Sendspin PCM encoding is little-endian throughout.

On a little-endian build those agree and nothing is wrong. On a big-endian one every decoded Opus sample reaches the device with its bytes reversed.

Nothing byte-swaps between the two, as far as I can see. If there is a swap somewhere I have missed, I would be glad to be corrected — that is the main reason I am filing this rather than a pull request.

Why I think it is worth looking at

The same shape of defect exists in two places around it, and in both I was able to demonstrate it rather than argue it:

• apply_volume() corrupts 16- and 32-bit PCM on big-endian hosts, against its own little-endian contract sendspin-cpp-cli#70 — apply_volume() honours its documented little-endian contract on its 24-bit path, written byte by byte, but reinterprets the buffer at native width for 16- and 32-bit. On MIPS big-endian under QEMU, 57 of 64 16-bit samples and 60 of 64 32-bit samples come back wrong, where x86_64 is exact.
• write_samples(): optimized paths emit native-endian PCM, so big-endian output depends on buffer alignment esphome-libs/micro-flac#36 — write_samples() packs byte by byte on its generic and 24-bit paths and casts on its optimized ones, and picks between them on buffer alignment. Same result: correct or corrupt depending on where the buffer landed.

Three places, one pattern: the careful path is byte-wise and the convenient path is a cast. This one is the third, and it is the only one of the three I did not manage to put under a test, because doing so means cross-building libopus for a big-endian target rather than compiling one self-contained file.

Context

Found packaging sendspin-cli for OpenWrt. ath79 — MIPS 24Kc, big-endian, still on kernel 6.18 — is a common host for this sort of thing: an older router with a USB port and a cheap DAC. My package carries @!BIG_ENDIAN for now, so it is simply not offered there rather than offered and wrong. I would rather drop that guard.

Happy to test a branch on real big-endian hardware, or to build the cross-compiled libopus harness if that would help more than it costs.

Environment

Library	sendspin-cpp v0.8.0, as pinned by sendspin-cli 0.3.0
Where	src/decoder.cpp, the opus_decode() call in SendspinDecoder::decode()
Consumer	ALSA sink opening SND_PCM_FORMAT_S16_LE

[mguaylam]

Reproduced now — I said above this was read-confirmed and not reproduced, and that cross-building libopus would cost more than it was worth. That turned out to be wrong: libopus is plain autotools, --host=mips-linux-gnu builds it in a couple of minutes, and the result is unambiguous.

The harness encodes a 1 kHz sine, decodes the packet through opus_decode() into a unsigned char buffer via the same (opus_int16 *) cast this code uses, and then reads the same bytes two ways: at native width, which is what the decoder wrote, and as little-endian, which is what a Sendspin sink consumes. Sample 500, past the encoder delay:

════════ x86_64 (little-endian) ════════
12 bytes in memory:   f0 ff f0 ff f0 ff f0 ff ec ff ec ff
read as little-endian:    -16     -16     -16     -16     -20     -20
read at native width:     -16     -16     -16     -16     -20     -20

════════ MIPS big-endian under QEMU ════════
12 bytes in memory:   ff d3 ff d3 ff d0 ff d0 ff c9 ff c9
read as little-endian: -11265  -11265  -12033  -12033  -13825  -13825
read at native width:     -45     -45     -48     -48     -55     -55

The proof stands inside the big-endian run alone, without comparing the two builds: the decoder wrote -45, the bytes in memory are ff d3, and a consumer reading little-endian gets -11265. A quiet passage comes out at roughly 250 times its amplitude, alternating sign — noise, not quiet audio.

On x86_64 the two readings agree, which is why nothing is wrong there and why this has not been noticed.

So all three of the byte-order defects I mentioned are now demonstrated rather than argued:

	Status
apply_volume() — Sendspin/sendspin-cpp-cli#70	reproduced
write_samples() — esphome-libs/micro-flac#36	reproduced, and gated on buffer alignment
opus_decode() — this one	reproduced

Glad to attach the harness, or to open a pull request adding it as a test.

Library	libopus 1.5.2, built from source for both architectures
Toolchain	mips-linux-gnu-gcc (Debian), -O2 -static
Runner	qemu-mips-static