Timestamps have been discussed in the logs 2. More drafting and 9. High-resolution timestamps. They should be reasonalby precise, useful and convenient. For example: time arithmetic is straight-forward, shifting a stream in time is a simple 32-bit addition with saturation.

This is different from many timing systems, such as sample-based timing which is too dependent of sampling rates, and n00n is meant to mix several streams with possibly irregular sampling rates. A fractional Herz system is the easiest common denominator and rounding to the next few points does add very minimal jitter.

65536Hz is also more fine-grained than the usual 44100Hz and 48000Hz sampling rates so the stream can be synchronised to within one sample.

There are two special values :

• Time zero (0x0000 : 0x0000) is the start of an actual track's contents.
• Time "min" (minimal) (0x8000 : 0000) corresponds to the least possible timestamp and means that the value is not valid so it is not to be trusted or taken into account (like a "no timestamp") and the schedule it taken from context and external data.

So there are two ranges of 32787 seconds, that's 546 minutes or a bit more than 9 hours, which should be long enough for long outtakes, rehearsals, you name it. And if it's not enough, it can be doubled because negative timestamps are totally fine, so the recording could be started from (0x8001 : 0000) and proceed up to (0x7FFF:FFFF). If the recording is longer than 18 hours and 12 minutes, the counter overflows to (0x8000 : 0000) to signal an invalid timestamp.

• The overflow is a corner case that must be properly managed by the DPLL,

• Erratic values must also be filtered out. The timestamp can suffer from some jitter and lag from networks but the overall speed should be within +/- 5% of actual real time to not be rejected.

• Gaps should also be gracefully handled. Maybe the timestamp is reset to minimal sometime during the recording, which could also be a case of two recordings that are merged.

Here are relevant Packet types:

-1 : Tick

It's just a header that is passed along the chain to synchronise all the other clocks downstream. No data payload. Upon reception :

• Make sure the time code is coherent (sample for 1 second ?)
• Update the local clock (and/or the soft PLL)
• Make sure that the Channel_ID does not collide (otherwise, rename yourself randomly and send a rename message downstream)

If no tick received within 1 second, send your own tick (8-16Hz ?)

-7 : JUMP

This special packet could be sent to warn about the shift to a different timestamp range, backwards or forward. The local timestamp counter is reset to a new value, but DPLL parameters should not be changed. Could be used to extend the duration of a recording or stream.

.