Files
OpsLog/internal
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-02 20:03:16 +02:00
2026-07-03 19:08:50 +02:00
2026-07-04 11:39:33 +02:00
2026-08-20 17:53:55 +02:00
2026-08-21 18:21:33 +02:00
2026-08-21 18:21:33 +02:00
2026-08-02 23:51:46 +02:00
up
2026-06-15 23:45:14 +02:00
2026-06-07 01:11:37 +02:00
2026-08-21 01:43:14 +02:00
2026-08-21 18:21:33 +02:00
2026-08-21 18:21:33 +02:00
2026-06-11 21:54:35 +02:00
up
2026-06-15 23:45:14 +02:00
2026-07-09 17:32:13 +02:00
2026-08-21 18:21:33 +02:00
2026-08-02 06:40:10 +02:00