[Ground-station] responses to more comments on ka9q-radio

[Phil Karn]

On 4/25/18 10:00, Michelle Thompson wrote:
> The ideal is to robust in the case of any (unpredictable) parameter update.
> 
> Current design seems to assume voice.

It doesn't assume anything. Only limitation is bandwidth, like any receiver.

> Relying on RTP to paper over the missing data works for voice. 
> 
> It dos not work for other classes of signals.

Not true. I'm specifically designing this to feed digital demodulators
and signal recorders as well as audio monitors. The actual output of
'radio' is an uncompressed 16-bit PCM stream, which any digital
demodulator would read directly; the Opus-compressed streams are for
consumption by the human ear only.

The most important thing for digital demodulation is to maintain a
correct sample count despite packet losses so the demodulator doesn't
see a sudden unexpected timing jump. I also want to maintain proper
timing in a recording despite silence suppression (.g., a closed FM
squelch).

RTP's timestamp field is specifically for this purpose. I can emit the
appropriate number of zero samples or flag an erasure or whatever the
demodulator prefers. The timestamp can jump either because of a lost RTP
packet or because of silence suppression but you can easily tell the
difference; if a packet is lost there will be a gap in the sequence
number but not in the case of silence suppression.

I expect RTP packet loss or out of order delivery to be rare since the
high data rate of uncompressed PCM will mean that demodulators are
usually run on the same LAN as the receiver.

All that stuff I put into 'monitor' for audio playout delay control is
totally specific to audio monitoring by a human. It is not used for
recording or digital demodulation since the RTP streams are read by
different programs. The digital demodulators process RTP differently as
they're not so concerned about minimizing delay. The 'iqrecord' program
is especially easy; it simply uses the timestamp to seek into the file
it's writing.

I've already written a AFSK/AX.25 demodulator that reads the PCM output
stream and emits AX.25 frames for other applications to process. Works
great.

> Being able to vary block size on the fly allows us to tune for latency.

I still don't understand the concern here. I have been using this stuff
almost continuously for months, for HF audio, VHF audio and AX.25
packet. I have yet to feel the need to vary the filter blocksize on the
fly. 20ms seems to suffice for everything, but of course it can be
changed by restarting the receiver. If a real need to change it on the
fly appears, I'll do it.

> We have an opportunity to craft some very useful code that takes full
> advantage of modern SDRs and current DSP techniques. There are a lot of
> other parameters besides filter stuff.

My goal here is to prove the concept of multicast RTP for SDR module
interconnection. My actual code is secondary, though I hope people will
find it useful.

Phil