Timestamp messages (0x00000001): Analysis

[honusz]

After doing some analysis of how authentic StageLinq devices interact, I have reached some conclusions about the 0x00000001 messages, which we refer to as timestamps.
Currently (ed23105 on main, 0bbed38 on listen), messageHandler() is discarding the token as a prefix (as it does for all messages), seeking past a second token, reading a Uint64 as bigint, and using that as timealive.

const id = ctx.readUInt32();
// FIXME: Verify token
ctx.seek(16); // Skip token; present in all messages
switch (id) {
	case MessageId.TimeStamp:
		ctx.seek(16); // Skip token; present in all messages
		// Time Alive is in nanoseconds; convert back to seconds
		this.timeAlive = Number(ctx.readUInt64() / (1000n * 1000n * 1000n));
		break;

After looking a bit at sequences of these timestamp packets, I'm not sure if the timestamp ends with a bigint of the milliseconds.

If, after the token, we take these as a 4 byte segment...

75 da d8 01
0f 15 d9 01
a8 4f d9 01
41 8a d9 01
da c4 d9 01
72 ff d9 01
0a 3a da 01
a3 74 da 01
3c af da 01

and read as a 32-bit unsigned integer with little endianness...

30988917 
31003919 
31018920 
31033921 
31048922 
31063922 
31078922 
31093923 
31108924

We get an incrementing number, which increments by 15001 (+/- 1). When we look at the time these messages were sent, they lineup almost exactly with the interval (~1.5 seconds).

Does this really matter for our purposes? For now, not really. It may be something we need to implement properly in order to behave like a good StageLinq device =)

My next step is evaluating the sequence of these timestamp messages. It may not seem super relevant for now, but I believe exhibiting proper behaviour with these messages may be necessary for implementing other services (syncing? beatinfo?).

[MarByteBeep]

Hi @honusz ! Thanks for doing so much investigation! This is weird, because when I run my code and output the time alive, I get sensible output: every 5 seconds my PrimeGo sends this message (u64 Big Endian), which exactly matches the time that the PrimeGo is alive. I believe the Go code uses an u64 value as well.

But when looking at your capture, it indeed looks like a 32 bit Little Endian value, that increments every 1.5 seconds. Which is also weird, because I don't get those messages at 1.5 second intervals, but at 5 second intervals.

Can you output the timeAlive in your example?

case MessageId.TimeStamp:
	ctx.seek(16); // Skip token; present in all messages
	// Time Alive is in nanoseconds; convert back to seconds
	this.timeAlive = Number(ctx.readUInt64() / (1000n * 1000n * 1000n));
	console.log(this.timeAlive);
	break;

[honusz]

Whoops, you're totally right.

I was looking at messages from the x1800, which are displayed as I posted.
But others use bigint timealive.

I'll post a more detailed update, but it's probably not relevant. Disregard 🤦🏻

[MarByteBeep]

Interesting that X1800 uses a different time format. Should we ever decide to support that device, we need to remember this ;)

[honusz]

Interesting that X1800 uses a different time format. Should we ever decide to support that device, we need to remember this ;)

I think it may have something to do with the token. The x1800 (the one I have anyway) starts with 0x00000000, but stagelinq, and others, start with 0xffffff. It's possible these first bytes are flags, indicating the behaviour the device expects or something.
As you say, something to keep in mind if it becomes necessary =)

[dzelionis]

I think ableton-link should do the same, i mean i did not do any captures on it, but after looking into source code of it...it feels like its has to synch a clock on both end devices, and thats really critical for calculate bpm, phase....also it uses a key for when encoding...

From Ableton Link documentation:
"Link works by calculating a relationship between the system clocks of devices in a session.
Since the mechanism for obtaining a system time value and the unit of these values differ
across platforms, Link defines a Clock abstraction with platform-specific
implementations"

[dzelionis]

FYI