PASS: 16-verify-tx-consistent.test
FAIL: 17-verify-tx-consistent-float.test
The FAIL is due inconsistency in the .wav header (only for floats)
constructed by libsndfile -- its different every wall-clock second.
Even just a bare header (no audio samples) shows the effect:
minimodem --float-samples --tx 1000 -f /tmp/xx.wav </dev/null
sum -r /tmp/xx.wav
sleep 1
minimodem --float-samples --tx 1000 -f /tmp/xx.wav </dev/null
sum -r /tmp/xx.wav
This might also relate to:
https://github.com/kamalmostafa/minimodem/issues/24
For non-interactive output (writing to an audio file), generate the
idle output carrier for same duration that the input is idle. Makes
this case generate an output .wav file of just over 1 second duration:
{ echo hello; sleep 1; echo world; } | minimodem --tx -f /tmp/xx.wav 300
Clean up the "emit idle tone" code, which should never have involved
tx_leader_bits_len (that was a copy-paste laziness).
"Emit idle tone" simply generates the idle tone for a hardcoded period
of time now codified as 'idle_tone_usec' and set to 1/25 of a second
(to match the existing behavior).
static analysis from clang scan-build detected some paths
in the call to fsk_frame_analyze where ampl_out is not being
set:
fsk.c:493:13: warning: Assigned value is garbage or undefined
best_a = ampl_out;
..probably the sanest approach here is to initialize it to 0.0
just to avoid it being garbage rather than setting it to zero in
the failed error paths in fsk_frame_analyze.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
The logic that determined whether to 'block_input' was backwards with
respect to non-interactive --file sessions, such that using --file
*enabled* the tx-carrier behavior when it should have disabled it.
This went unnoticed because on reasonably fast systems, reading the
input data from the file never induce the timeout anyway -- only very
slow machines reveal the problem: long gaps of 'mark' between each
frame, as if each input character was slowly typed interactively.
Fixes: ecebf01 Add ability to output a carrier while waiting for data
With arbitrarily large latency setting (unsigned int)-1, ALSA will happily
accept all the samples we want to throw at it.
Reducing to a reasonably long (but still sub-second) value of 100ms, we
cause ALSA writes to block and work properly with --tx-carrier.
Jannis R