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>
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
Steve Pinkham
Steve Pinkham
as3ii
DJ2LS
DJ2LS