Re: supernova sample-based scheduling bug?

> From my own experience with an older patched version of SuperCollider
> that could actually schedule at specific sample indices since the
> start of the server I know that is possible. Only one reference point
> with a time stamp connected to a sample index was enough to keep
> sample-sync operation, even over multiple machines, up for quite a
> long time with latencies around the normal 0.2s.
I think you were just being lucky. Unless the language scheduler itself
is also driven by the audio hardware clock, it will always use a
different clock source than the Server and the two clocks will
eventually drift.

If the client clock is running *faster* than the Server clock, the
Server will just slowly accumulate bundles.

If the client clock is running *slower* than the Server clock, you will
eventually get late bundles. Howerver, using a rather high Server
latency (like 0.2s), it takes some time until this happens.

So this is still not a universal solution, I think.

Christof

On 20.05.2021 15:20, [email protected] wrote:
> Hi Daniel and Christof,
>
> yes, indeed NTP scheduling is not sample accurate. I had hoped though
> that the sampleclock based implementation of supernova could somehow
> bypass that problem. Otherwise; why is it there? From my own
> experience with an older patched version of SuperCollider that could
> actually schedule at specific sample indices since the start of the
> server I know that is possible. Only one reference point with a time
> stamp connected to a sample index was enough to keep sample-sync
> operation, even over multiple machines, up for quite a long time with
> latencies around the normal 0.2s. In that case it would predict the
> sample index based on time passed since the reference measurement, and
> encode that in the bundle timestamp (which was the patched part of
> that version). I was hoping that supernova was doing something like
> that as well, but perhaps the normal NTP time stamp resolution is too
> low for that? Or the bundle timestamp sent with the messages is not
> actually based on logical time? Or is it that SystemClock time != NTP
> time?
>
> In any case, it would be very handy, and as far as I can tell also
> possible, to have actual sample based timing in SC if somehow actual
> sample indices could be sent with OSC messages.
>
> cheers & thanks,
> Wouter
>
>
>
>> Op 20 mei 2021, om 00:38 heeft [email protected]
>> <mailto:[email protected]> het volgende geschreven:
>>
>> Hi,
>>
>> I’ve described this behaviour also here, you can try improve by
>> tweaking the hardware buffer size but essentially you can’t get
>> around it with dynamic language time base as Christof pointed out.
>> You can use NRT though.
>>
>> https://scsynth.org/t/imperfection-of-language-based-timing/350
>> <https://scsynth.org/t/imperfection-of-language-based-timing/350>
>>
>> Cheers
>>
>> Daniel
>>
>>
>>
>