Re: [time-nuts] an interesting timing problem

2020-05-06 Thread Steven Sommars
This discussion focuses on interactive audio/data streams. One-way streams are treated differently, since delay is less important. Media transport typically uses IPv4/6 networks and can often be captured at one of the endpoints or somewhere in the network path. E.g., I captured a Skype call

Re: [time-nuts] an interesting timing problem

2020-05-06 Thread Joseph Gwinn
frequency measurement > > Subject: [time-nuts] an interesting timing problem > Message-ID: > Content-Type: text/plain; charset=utf-8; format=flowed > > Given that there's a lot more people spending time zooming, webexing, > teaming, skype, facetime, etc. these days, I'm curious

Re: [time-nuts] an interesting timing problem

2020-05-06 Thread jimlux
On 5/6/20 7:33 AM, Chris Howard wrote: At my current job we were looking into delay timings of video systems. We were doing end-to-end measurement by putting a time display in front of a monitor and have the camera show both the time display and the monitor. It looks a bit like the old

Re: [time-nuts] an interesting timing problem

2020-05-06 Thread Anton Strydom
Good day Easy way of testing such is to make a skype or team viewer call and then get the other side to synchronize the computer that side as simultaneously as possible with you by click on change date and time settings and then Internet time. It for a few seconds are absolutely perfect but

Re: [time-nuts] an interesting timing problem

2020-05-06 Thread Chris Howard
At my current job we were looking into delay timings of video systems. We were doing end-to-end measurement by putting a time display in front of a monitor and have the camera show both the time display and the monitor. It looks a bit like the old infinite mirror. If you arrange things right

[time-nuts] an interesting timing problem

2020-05-06 Thread jimlux
Given that there's a lot more people spending time zooming, webexing, teaming, skype, facetime, etc. these days, I'm curious if anyone has figured out to *quantify* the issues of lag, desynchronization, etc. How would one go about instrumenting it (without access to the source code or servers