With blocksize=0 PortAudio picks the capture block size per device. On
the devices measured for the previous commit it happened to deliver
multiple-of-6 block sizes, but other hardware returns 512/1024-class
blocks. codec2's resample48_to_8 asserts len(input) % 6 == 0
(FDMDV_OS_48), so on such a device every captured block raised
AssertionError, the DSP chain never ran, and RX was completely deaf.
The fix decouples the capture block size from the DSP block size
instead of pinning the stream back to blocksize=4800, which is the
configuration that negotiates a two-period ring on snd-aloop and drops
audio continuously (the deaf-on-loopback case the previous commit
fixed). Captured audio is appended to a carry buffer and the DSP chain
runs once per whole RX_DSP_BLOCK_48K (4800 samples, 100 ms) available;
the remainder carries into the next captured block, so the sample
stream handed to the resampler stays gapless (its filter memory spans
blocks) and always has a valid length, whatever the device delivers.
Running the DSP only on whole 4800-sample blocks also fixes three
silent degradations that short blocks caused:
- calculate_fft pads its input to 800 samples at 8 kHz, so short
blocks fed the waterfall, channel-busy detection and audio_dbfs
mostly zeros
- enqueue_streaming_audio_chunks zero-pads every block up to 2400
samples and emits one chunk per block regardless of size, so short
blocks streamed mostly silence and flooded the RX audio queue
- normalize_audio (rx_auto_audio_level, on by default) normalizes per
block, so shorter blocks made the auto level faster and jumpier
Tests: the old test captured 4800-frame blocks, a multiple of 6, which
is exactly why this was never caught. The capture size is now 512 and
TestRxAudioReblocking covers odd sizes never reaching the resampler,
exact block accounting including the carried remainder, sample-stream
preservation (nothing dropped, duplicated or reordered), and every
re-blocked block being accepted end to end by the real codec2
resampler. Against the pre-fix code 5 of the 6 tests fail; with the
fix all pass.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
blocksize=4800 makes PortAudio hand the RX callback fixed 100 ms blocks,
so received audio sits in the input buffer for up to 100 ms before the
demodulator can see it, and that delay is paid again on every ARQ
turnaround. With blocksize=0 PortAudio delivers whatever is available
(small blocks in the 10 to 50 ms range in our measurements), cutting the
RX buffering delay to a fraction of the old fixed block.
On its own, blocksize=0 also shrinks the negotiated input ring. We
measured 40 ms total where blocksize=4800 had negotiated 200 ms on a
CM108 USB codec, which makes short processing stalls more likely to
drop audio. The explicit latency=0.2 closes that gap: it requests a
200 ms ring built from small periods, so the stream keeps the old depth
while gaining the low latency.
The explicit ring depth also makes the negotiation deterministic on
virtual devices. On snd-aloop (the ALSA loopback used for hardware-free
testing) the default "high" latency maps to only two periods. At 100 ms
periods that double buffer misses its service deadline on a fixed cycle
and the capture stream drops audio continuously from the moment it
opens, leaving the modem deaf on that device class. With an explicit
depth the same stream runs clean; we measured buffer 12000 frames with
2400 frame periods and zero overflows, identically on two machines.
TX stays at blocksize=2400; only the RX side changes.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The sounddevice RX callback did all of the RX DSP inline: resample 48->8 kHz,
an FFT for the spectrum / channel-busy detection, optional level normalisation,
and a push into every decode mode's demod buffer. Running that on the real-time
audio thread means any delay in it -- a long GIL hold by another thread, a slow
resample on a constrained CPU -- can push the callback past its deadline and
overflow the capture stream.
Make the callback real-time-safe: it now only copies the captured block onto a
queue and returns. A dedicated worker thread (rx_audio_processing_worker) drains
the queue and runs the same DSP. The audio thread's work is now bounded and
constant.
This is also a prerequisite for lowering the input blocksize (next commit): a
smaller blocksize means a shallower capture ring, which only stays safe once the
DSP is off the real-time thread.
The DSP itself is unchanged -- the processing is moved verbatim, not altered.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The IRS success branch set ENDED and returned without the
session-finished event, while abort, failure and the ISS success path
all send one. A successful inbound raw transfer was invisible to every
websocket/REST consumer, and the received payload was dropped with it
(handle_raw returns the data into a call chain that discards it).
c2388a65 emitted exactly this event, data= included; it vanished by
ef18f4cc without that commit's IRS diff touching the lines, so this
looks like a merge casualty rather than a decision. Restore the event
and add a regression test: one finished event with success=True,
payload round-trips through the base64 data field.
The original also pushed session statistics gated on enable_stats, but
that key is no longer in the config schema (config.py STATION), so the
strict lookup raises KeyError; the two existing stats sites in the
failure and abort paths have the same latent problem. Restoring just
the event here; the stats question is worth its own look.
No setARQ(False) here: dispatch() already clears busy on this path.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
command_arq_raw.SendARQRawCommand isn't defined anywhere; the class is
ARQRawCommand. The always-503 busy bug hid this AttributeError, so the
endpoint can never have worked end to end.
POST /modem/send_arq_raw returned 503 Modem Busy on every request:
is_modem_busy is a threading.Event and the object is always truthy.
Use getARQ() like the beacon, message send and CQ handler do.
Note for later readers: is_set() would be inverted, since setARQ(True)
clears the event. getARQ() == True means busy.
See: https://peps.python.org/pep-0008/#imports
Here absolute imports have been used to avoid the error
`ImportError: attempted relative import with no known parent package`.
This applies mostly the same rules that `black` used.
This commit should not have introduced any logical or functional
changes, only fixing style consistency
Not sure if a bug unique to python on windows, but rigctl chk_vfo and dump_caps would not work until I escaped the \'s in the funcitons remarks. Rigctl would not work at all because of these errors.
Steve Pinkham
Steve Pinkham
dj2ls
DJ2LS
Mashintime
as3ii
Erik de Wildt
Mashintime