<div dir="ltr">OK, I think I understand what you're saying here.<br><br>Thank you for the clear demonstration of the value of RTP multicast.<br><br>I think it can be translated, almost literally, into GNU Radio blocks. I don't see anything quite like it as a block in GNU Radio right now. <br><br>We spent some of yesterday working with codec2 blocks in the lab. I don't see Opus on the list of codecs in GNU Radio. I think it would be a great addition. <br><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr">-Michelle W5NYV<br><br><div dir="ltr"><br></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Thu, Apr 26, 2018 at 11:47 AM, Phil Karn <span dir="ltr"><<a href="mailto:karn@ka9q.net" target="_blank">karn@ka9q.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 4/25/18 10:00, Michelle Thompson wrote:<br>
> The ideal is to robust in the case of any (unpredictable) parameter update.<br>
> <br>
> Current design seems to assume voice.<br>
<br>
</span>It doesn't assume anything. Only limitation is bandwidth, like any receiver.<br>
<span class=""><br>
> Relying on RTP to paper over the missing data works for voice. <br>
> <br>
> It dos not work for other classes of signals.<br>
<br>
</span>Not true. I'm specifically designing this to feed digital demodulators<br>
and signal recorders as well as audio monitors. The actual output of<br>
'radio' is an uncompressed 16-bit PCM stream, which any digital<br>
demodulator would read directly; the Opus-compressed streams are for<br>
consumption by the human ear only.<br>
<br>
The most important thing for digital demodulation is to maintain a<br>
correct sample count despite packet losses so the demodulator doesn't<br>
see a sudden unexpected timing jump. I also want to maintain proper<br>
timing in a recording despite silence suppression (.g., a closed FM<br>
squelch).<br>
<br>
RTP's timestamp field is specifically for this purpose. I can emit the<br>
appropriate number of zero samples or flag an erasure or whatever the<br>
demodulator prefers. The timestamp can jump either because of a lost RTP<br>
packet or because of silence suppression but you can easily tell the<br>
difference; if a packet is lost there will be a gap in the sequence<br>
number but not in the case of silence suppression.<br>
<br>
I expect RTP packet loss or out of order delivery to be rare since the<br>
high data rate of uncompressed PCM will mean that demodulators are<br>
usually run on the same LAN as the receiver.<br>
<br>
All that stuff I put into 'monitor' for audio playout delay control is<br>
totally specific to audio monitoring by a human. It is not used for<br>
recording or digital demodulation since the RTP streams are read by<br>
different programs. The digital demodulators process RTP differently as<br>
they're not so concerned about minimizing delay. The 'iqrecord' program<br>
is especially easy; it simply uses the timestamp to seek into the file<br>
it's writing.<br>
<br>
I've already written a AFSK/AX.25 demodulator that reads the PCM output<br>
stream and emits AX.25 frames for other applications to process. Works<br>
great.<br>
<span class=""><br>
> Being able to vary block size on the fly allows us to tune for latency.<br>
<br>
</span>I still don't understand the concern here. I have been using this stuff<br>
almost continuously for months, for HF audio, VHF audio and AX.25<br>
packet. I have yet to feel the need to vary the filter blocksize on the<br>
fly. 20ms seems to suffice for everything, but of course it can be<br>
changed by restarting the receiver. If a real need to change it on the<br>
fly appears, I'll do it.<br>
<span class=""><br>
> We have an opportunity to craft some very useful code that takes full<br>
> advantage of modern SDRs and current DSP techniques. There are a lot of<br>
> other parameters besides filter stuff.<br>
<br>
</span>My goal here is to prove the concept of multicast RTP for SDR module<br>
interconnection. My actual code is secondary, though I hope people will<br>
find it useful.<br>
<span class="HOEnZb"><font color="#888888"><br>
Phil<br>
</font></span></blockquote></div><br></div></div>