Conversation
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>
Exercise the callback/worker split from the previous commit: - the worker drains rx_audio_in_queue and runs the relocated RX DSP (resample 48->8 kHz, FFT, demod-buffer push) on an enqueued block, and - the callback drops (and counts via rx_audio_dropped_blocks) instead of blocking when the queue is full -- the real-time-safety property the change exists to provide. Both feed synthetic int16 blocks straight to the callback, so they need no audio hardware and run under the existing `unittest discover tests` suite. The live ARQ transfer test uses an in-memory queue and never touches the sounddevice path, so this is new coverage rather than a changed test. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
… depth explicitly 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>
pip adjustments and possible fix for nsis
Lower RX audio latency and make the input callback real-time safe
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>
fix(audio): re-block captured RX audio into whole DSP blocks (fixes the AssertionError from #1112)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.