Get stable timing information into the RTP streams/ RTCP sender reports. Also into pcmrecord output.

[pjsg]

I'd like to get accurate timing information into the pcmrecord output. Probably using the BWF extension (https://tech.ebu.ch/docs/tech/tech3285.pdf#page=9) to the WAV file format. This is just another information block that defines an accurate timestamp of the first sample in the file. It actually includes the number of samples since midnight, along with a standard date/time. The result is still readable as a WAV file.

For pcmrecord to be able to do this, it needs to extract the timing information from the RTP stream -- but that is just a sample number since some start time. RTCP sender reports contain the mapping from sample number to absolute time (only I don't think that the current code generates that information correctly).

The absolute time of the USB transfers from the RX-888 are generated, though they don't flow through the filtering and demod phase. I have no idea what the delay inside the RX-888 is, but I suspect that it is < 50μS. I haven't thought about the other front-ends.

I'd like to be able to get (from the pcmrecord output) the timestamp of the signal to within 1mS. Using the WWV transmissions would allow determination of whether the end-to-end flow works. For me, the light speed delay from WWV is around 12mS -- and I like to see a number around that value.

[ka9q]

Hi Phil, I recently added the RTP_TIMESNAP field to the status message, and I also now carry the input sample counter for each frame through the downconverter filter so it appears as INPUT_SAMPLES. (That value used to come directly from the front end so it was affected by latency). This lets you tie a specific RTP timestamp to a specific input A/D sample. Of course the output is decimated from the input so they run at different rates. If the input sample rate is 126 MHz (what I use with the RX888) and the block time is 20 ms (50 Hz), INPUT_SAMPLES will increment by 126,000,000/50 = 2,520,000 every 20 ms, and if the output sample rate is 12 kHz then RTP_TIMESNAP will increment by 12,000/50 = 240 every 20 ms, for an overall decimation ratio of 10,500:1. I put a hook into my monitor program that calculates the input sample # corresponding to timestamp 0 for that stream, and it's rock stable.

The status message also contains GPS_TIMESTAMP though it comes from the Linux system clock so it's only good to a few ms; for it to to mean what it says, the system would need its own GPS receiver. I just like the GPS timescale because it doesn't have leap seconds.

[pjsg]

I'll take a look at this -- probably at the weekend.

Thanks.

[pjsg]

I did look -- and it looks like it is working fine. Thank you.