Granulated or stuttery box audio
Symptom
The stagebox establishes cleanly. Phantom power works. The meters look right. The audio is granular — a fast, grainy stutter, as though every short block of sound were being played twice or chopped.
It sounds exactly like a broken decoder. It is almost never a decoder.
There are two causes, and they produce the same sound.
Cause 1: the segment changed rate without re-pacing the box
A stagebox runs at the pace its segment is clocked at, 44.1, 48 or 96 kHz, the rates a Roland desk uses, and it follows the pace it is given. What granulates is a segment whose rate was changed while the box was established without the segment being re-opened at the new pace: the box keeps counting at the old one and the stream arrives torn. The console's REAC daemon re-opens the segment on every rate change since version 0.4.5, so this is rare now, but a segment that was already running when the daemon was upgraded can still be in that state.
Check
Open the REAC clock panel. Each segment shows its pace and its box. Compare the pace with what the box reports in the same panel; a mismatch is the fault.
Fix
In the same panel, set the segment's rate again, to the value you want; the box re-paces in about two seconds and the audio is clean. Everything is done with the console's controls; there is no configuration file to edit and nothing to restart. If you want the graph itself at another rate, that is the clock on the Setup page, and it is described in clocking and sample rate.
Cause 2: frames are arriving twice
A mirrored (SPAN / monitor) switch port delivers every frame twice — the real frame and the mirror copy, in both directions. Every block of audio is then assembled twice, and the result is the same granular stutter.
Nothing else looks wrong: the box establishes, phantom works, metering is correct. That is what makes this one expensive to find.
Check
Turn on the transport's counters:
systemctl --user edit reac-pw
[Service]
Environment=REAC_DEBUG=1
systemctl --user restart reac-pw
journalctl --user -u reac-pw -f
Roughly every two seconds it reports received, duplicate, other-source, bad and gap counts. On a correctly-cabled interface the duplicate count is zero. Anything else means duplicated delivery.
Fix
Move the transport onto a dedicated, non-mirrored interface — a direct cable to the
box is the simplest correct topology — and set REAC_LIVE_IFACE / REAC_TX_IFACE in
Setup → Adapters → REAC to match.
The transport does drop byte-identical duplicate frames, and that guard is what makes a mirrored link sound clean, so you may not hear the fault at all. Do not rely on it. It is a robustness guard against any duplicated-delivery path; it is not a supported topology, and it costs you the ability to tell a real duplicate from a wiring mistake. On a correctly-cabled interface it does nothing.
Turn REAC_DEBUG off again when you are done.
What it is not
Two things that have been suspected and cleared:
- Not a decode bug. Individual samples decode correctly; the fault is in how frames are assembled, not in how bytes are read.
- Not the box misbehaving. A stagebox sends each frame once, slaved to the master's clock. If you are seeing every frame twice, something between the box and the socket is duplicating it.
Still granular?
Check the obvious in-graph causes before going further: another application fighting for the device, a plugin chain running out of time (the telemetry panel's xrun counter will show it), or a CPU governor pinned low. See xruns and driver election.