<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>
<blockquote type="cite">so what i'm really suggesting to "fix" the
timestamps in [packOSC] is to use logical time for *advancing
time* (and add some offset to put the timestamps into the same
calendar as NTP)
</blockquote>
This corresponds to 2) in my previous mail. While this sounds
simple in theory, in practice you will encounter problems with
clock drift sooner or later. Supernova had to introduce an option
to use the system time instead of the logical time because some
users had experienced issues. For a drastic example, search for
"timing drift supernova" in<a
href="https://www.listarc.bham.ac.uk/lists/sc-dev-2014/search/">
https://www.listarc.bham.ac.uk/lists/sc-dev-2014/search/</a></p>
<p><br>
</p>
<p>In Pd there is another issue with advancing by logical time: Pd
has very relaxed realtime-safety constraints and it is very common
to occasionally drop some audio blocks, e.g. when opening a large
patch or loading a large soundfile. Naturally, the logical time
does not advance while Pd blocks, so your timestamps will be late
forever.</p>
<p><br>
</p>
<p>FWIW, here's my current approach to scheduling/dispatching OSC
bundles in Pd (for the next AOO release):</p>
<p>1) sample the system time *once* per DSP block</p>
<p>2) filter the time with a DLL to get rid of jitter<br>
</p>
<p>3) check for dropped audio blocks and resync the time base. This
is hard to do in a plugin. The best solution I've come up with so
far is to average the last few delta times and check if it rises
above a certain threshold.</p>
<p><br>
</p>
<p>All of this steps wouldn't be necessary if Pd would</p>
<p>1) give access to the (estimated) system time of the current DSP
tick</p>
<p>2) resync the system time and send a notification (e.g. a message
to "pd") when the polling scheduler has to drop a block of audio </p>
<p>There's still a potential problem with xruns in the audio driver.
Jack has a xrun callback
(<a class="moz-txt-link-freetext" href="https://jackaudio.org/api/group__ClientCallbacks.html#ga08196c75f06d9e68f9a3570dfcb1e323">https://jackaudio.org/api/group__ClientCallbacks.html#ga08196c75f06d9e68f9a3570dfcb1e323</a>).
Portaudio has input/output overflow/underflow flags that are
passed to the stream callback, but it's up to the audio driver to
actually provide this information. I've read somewhere that many
ASIO drivers don't do this...</p>
<p>Christof<br>
</p>
<div class="moz-cite-prefix">On 19.04.2021 09:17, IOhannes m
zmoelnig wrote:<br>
</div>
<blockquote type="cite"
cite="mid:8776d4a7-4460-64d9-26f9-abc84b6be8fc@iem.at">On 4/18/21
10:32 PM, IOhannes m zmölnig wrote:
<br>
<blockquote type="cite">
<br>
i checked and double checked the specs but could not find
anything about this.
<br>
where do you get the idea that the OSC specs mandate wall clock
time?
<br>
OSC-1.0 speaks about "NTP format" (but this is just the
structure of the 64 bits data chunk) and "the number of seconds
since midnight on January 1, 1900" (but it doesn't say whether
this is supposed to be wallclock or idealized)
<br>
</blockquote>
<br>
i just thought that maybe we are really talking about different
things here.
<br>
<br>
so i'd like to clarify what I mean by "logical time".
<br>
<br>
Pd keeps an track of an internal monotonic value "pd_systime" that
is incremented whenever time advances within the Pd world.
<br>
the incrementation of this value is losely synched to the passing
of time in the real world ("wall clock time").
<br>
"losely" insofar as the increments do not happen at exactly the
same time, but the maximum difference between the wall clock time
and the logical time is bound to a somewhat small value
(<<1sec).
<br>
<br>
wall clock time is typically provided by the OS by means of
gettimeofday() or similar.
<br>
<br>
while the two times are synched, they have different offsets.
<br>
Pd's logical time simply starts whenever the Pd instance started.
<br>
however, gettimeofday() counts seconds since the beginning of the
epoch (currently: 1970-01-01 00:00).
<br>
<br>
to complicate things, NTP-timestamps (as used by OSC) use their
own epoch that starts on 1900-01-01 00:00.
<br>
<br>
<br>
using Pd's logical time "as is" as an OSC timestamp, is of course
useless (unless you are communicating withing the same
Pd-instance), as all participants need to agree on a common epoch.
<br>
<br>
so what i'm really suggesting to "fix" the timestamps in [packOSC]
is to use logical time for *advancing time* (and add some offset
to put the timestamps into the same calendar as NTP)
<br>
<br>
so basically:
<br>
- when packOSC gets instantiated, determine the offset of the
logical time with respect to the NTP time.
<br>
e.g.:
<br>
offset=seconds_from_1900_to_1970+gettimeofday()-sys_getlogicaltime()
<br>
- when creating a timestamp, use this to calculate the ideal NTP
time:
<br>
now=offset+sys_getlogicaltime()
<br>
<br>
<br>
in the actual implementation there's two issue that should be
addressed:
<br>
- probably the synching of logical time to wall clock time (that
is: the calculation of the offset) should only be perfomed once
for all the [packOSC] and [unpackOSC] objects in the running
instance, so they are all tightly synched.
<br>
- make sure to handle epochs correctly (the next unix epoch starts
in 2038; this is still far in the future for many, but for
[packOSC] birthday is about as far in the past)
<br>
<br>
gfmsdtf
<br>
IOhannes
<br>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
<a class="moz-txt-link-abbreviated" href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list
UNSUBSCRIBE and account-management -> <a class="moz-txt-link-freetext" href="https://lists.puredata.info/listinfo/pd-list">https://lists.puredata.info/listinfo/pd-list</a>
</pre>
</blockquote>
</body>
</html>