Adds support to pcmrecord to add the 'bext' chunk to WAV files if RTCP is enabled

[pjsg]

This is a first attempt at solving (part of) the improved timing of capture files (issue #186 ). I think that it works, but the problem is that the radio.c rtcp_send doesn't construct the sender report correctly. The fields around this are all badly named -- the rtp_timestamp field in the sender report corresponds to the timestamp field in the RTP data packet -- and this is actually measured in units of samples.

I beleive that the code change in pcmrecord.c does implement this correctly, but I need to figure out how to adjust the code in radio.c to send the right information. [To be honest, I'm very unclear on how to compute the processing delay from receiving the samples from the frontend all the way to assembling them into a packet]

If there is no RTCP being sent by radio.c, then the bext chunk will not be added (it is actually replaced by a JUNK chunk).

[pjsg]

This is the code from radio.c that constructions the ntp_timestamp and the rtp_timestamp:

    // Construct NTP timestamp (NTP uses UTC, ignores leap seconds)
    {
      struct timespec now;
      clock_gettime(CLOCK_REALTIME,&now);
      sr.ntp_timestamp = ((int64_t)now.tv_sec + NTP_EPOCH) << 32;
      sr.ntp_timestamp += ((int64_t)now.tv_nsec << 32) / BILLION; // NTP timestamps are units of 2^-32 sec
    }
    // The zero is to remind me that I start timestamps at zero, but they could start anywhere
    sr.rtp_timestamp = (0 + gps_time_ns() - Starttime) / BILLION;

I think that the last line is missing a multiply by the sample rate -- but that isn't right either as it doesn't take into account the delay through the processing chain and any inaccuracies caused by the sampling rates not being exactly right. I also don't know if the 0 is actually right either as it ought to depend on when the first rtp data packet is sent.

I got really confused when I started to think about leap seconds and the fact that the occasional day has more samples than other days.

[ka9q]

I never actually used the rtcp code; it's incomplete and untested. Admittedly some of the functionality in my custom status protocol really ought to be in RTCP, specifically the NTP timestamps. They're intended for just what we want, relating a particular 32-bit RTP timestamp value to wall clock time. You're not missing anything, all this stuff is still very new and experimental, and I need to do a formal deep dive on the delay sources in ka9q-radio. The HamSci engineering group is converging on applying a GPS 1 pps pulse to BPSK modulating a locally generated carrier at some convenient level and frequency and injecting it into the SDR front end. That would provide an actual end-to-end measurement of all delays in the receiver, including the hardware and USB subsystem. As long as the bandwidth of the receiver channel tracking the 1pps pulse is at least as wide as the user channels, the precision should be sufficient for those applications.

[pjsg]

I was hoping that a reasonable estimate of the delay could be acquired from monitoring WWV (after compensating for lightspeed delays). I agree that adding a GPS sync pulse would be better, but it requires more circuitry!

[ka9q]

Have you talked with Michael Hauan, AC0G and Scott Newell N5TNL? I know Scott has already done some cool stuff with WWV seconds ticks and minute beeps.

[ka9q]

Please take a look at my recent changes to how I generate RTP_TIMESNAP and INPUT_SAMPLES and let me know if you still want me to accept your pull request.