Accurate timestamps possible?

[Anders Bech Mellson]

I want to build a precise synchronisation algorithm for a networked music application.

 

Is it possible to get the timestamp of a received network packet from the hardware layer?

 

I would like to avoid the time it takes to receive the message before getting a timestamp.

[Joshua Pollack]

Network packet ala ethernet frame which contains most likely a UDP datagram?

No, If I understand your question correctly, to the best of my
knowledge Apple doesn't expose anything even close to this sort of
"real" access via their APIs. I'm guessing you want a hardware
timestamp to try and implement something like PTP? Like using the
SO_TIMESTAMPING socket option on linux?

That being said, I did a few minutes of googling and saw that ptpd
does work on osx, so maybe you'll get lucky and be able to crib notes
from that code. Just a guess.

I'm somewhat of a timing dork -- for the past year I've been working
on several related things, including an (unfinished) in-process
implementation of a hybrid NTP/PTP algorithm, so I can try to get some
amount of synchronization.

I am quite curious what your project is though. :) If you don't mind
my asking, what's your larger project/motivation?

Joshua

> --
> You received this message because you are subscribed to the Google Groups
> "Open Music App Collaboration" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to open-music-app-colla...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Joshua Pollack]

I may have spoken too soon! I thought that SO_TIMESTAMPING was a
linux-onlyism. I'll save you some research, but here's a copy of
socket.h, which clearly includes SO_TIMESTAMP, which should let get
https://gist.github.com/cyberroadie/3490843

a 'struct timeval' of when the last packet was passed to the users.

So, I'd try coding something up and seeing if it works -- and let us know!

Joshua

[Anders Bech Mellson]

Thanks very much for your replies. I will see if SO_TIMESTAMP is a viable approach!

I am building an application which, hopefully, can generate reliable time code on each node that is running the application.

Currently I am targeting OS X and iOS, and therefor both wired and wireless connections.

The plan is to see how accurate the syncing can get in this very open scenario.

I will update this post with some numbers when I have something interesting to share.

Kind regards,

Anders

>> email to open-music-app-collaboration+unsub...@googlegroups.com.

[David Warman]

Google for the phrase 

"WO1998006194A1-Clock_Sync.pdf patent". 

I wrote this in 1996. It's a system for getting 44K1 sample-accurate synchronization amongst network nodes that have independent time clock hardware, and therefore drift relative to each other. The company it is credited to - MediaLink - went out of business in 1997, and we (the founders and inventors) were given back the MediaLink tecnology. Including this one. It is frankly a puzzle to me that it is not listed as abandoned, and has action times after that, but still.... probably burocratic inertia.

I would like to see it get used. One caveat - the cpu's I wrote this for had user code accessible hardware timers. But also only 2.5 MHz clock, so the 1000x we have today may copensate for the lask of such access.

The google results will find this, but also of interest are the hits to other patents that cite this one. You may want to be careful not to infringe on them, but please use mine. If you will. It would be comforting to see some usefulness result from that effort.

Best,

David Warman

On Wednesday, February 18, 2015, Anders Bech Mellson <and...@bechmellson.com> wrote:

Thanks very much for your replies. I will see if SO_TIMESTAMP is a viable approach!

I am building an application which, hopefully, can generate reliable time code on each node that is running the application.

Currently I am targeting OS X and iOS, and therefor both wired and wireless connections.

The plan is to see how accurate the syncing can get in this very open scenario.

I will update this post with some numbers when I have something interesting to share.

Kind regards,

Anders

--
- David Warman

[Rob Fielding]

Watch some QoS videos, as this topic clearly explains the problem.

The best you can do is to timestamp events on the side that generates events, and increase latency until jitter can be zero. The timestamps can only accurately describe the spacing of events (ie: playout). Each side has its own clock, they cannot really be assumed to be equal, but they can be assumed to tick at the same rate.

The idea is to have a playout buffer to space events on the synth side in exactly the same way they were spaced on the controller side.

Trying to achieve this at the level of the network stack can't work; though take a look at udp, rtp (or any modern equivalents). The timestamps need to be the time of the app event (like finger down), not the time a packet is egressed. Ie: the stamps must be written into osc/udp packets or midi packets, etc.

Rcvr must buffer those packets as soon as it gets them (not play them as asap).

Sent from my iPhone, which is why everything is misspelled. http://rfieldin.appspot.com
http://rrr00bb.blogspot.com

[Anders Bech Mellson]

Wow, thanks! That looks very helpful.

This application I am working on is for my M.Sc. Thesis in software development.

So I actually hadn't thought about patent infringement.

But thanks for raising the point, I will make sure to look into it before any potential release.

Kind regards,

Anders

[Anders Bech Mellson]

Thanks for the tip, I will look more into QoS.

I am indeed looking at a buffered solution, where my main assumption is that the clock on every node is ticking at roughly the same interval.

But I do think, like you, that my solution will be highly affected by the quality of the network.

What I want to look into is how "bad" can the network be for my solution to still be "good enough".

If I am able to get the timestamp of receiving messages at the hardware layer that will be a good starting point.

Because this can be combined with the fact that a multicast message will arrive at all nodes at the same time.

Other algorithms I have found, for instance the Reference Broadcast Synchronization, exploit this fact.

But I am still to confirm this on my own network setups.

Kind regards,

Anders