Files
OpsLog/internal/cat
rouggy 9b8168370f fix(tci): derive the sample width instead of trusting the format number
A real SunSDR answers format=3 where this expected 0 — and 0 was read
from the documentation, which is exactly the kind of detail a memory of a
document gets wrong. The stream was refused outright: 'format=3, expected
float32', zero frames, silence.

Swapping one magic number for another would only move the guess, so the
width is now MEASURED: the header says how many samples the payload
holds, and dividing gives the bytes per sample. Four is float32, two is
16-bit PCM scaled to the same -1..1 the rest of the audio path uses, and
anything else is reported rather than mangled. That stays true whatever
number the format field carries on the next firmware.
2026-08-24 22:36:21 +02:00
..
2026-08-21 23:28:55 +02:00
2026-07-26 16:57:19 +02:00