Re: supernova sample-based scheduling bug?

It might be an interesting option for some users to have. If you have
time, make a PR!

Am 21.05.2021 um 21:20 schrieb [email protected]:
> Hi Christof,
>
>> Op 20 mei 2021, om 15:58 heeft [email protected]
>> <mailto:[email protected]> het volgende geschreven:
>>
>>
>>> 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.
>>
> Yes indeed the clocks will drift apart. They drift apart more with
> builtin mac audio than with a properly clocked audio interface, we
> measured. Still the the timing was (and is, as the system using this
> is still running and functional) perfectly sample-sync, the test that
> I posted earlier here would render perfect results for very long
> times. Only when a sample was skipped by the server (for example a cpu
> overload or a hardware failure) it would fail, logically. We actually
> experienced very little clock drift, it was very useable to work with,
> within the 0.2s latency frame. And the system had a simple re-sync
> procedure to be used when the clocks were too far apart. We advised
> users to do that every now and then, and for example at the start of a
> concert, also to be able to detect any hardware issues (which would
> immediately show up as fluctuating sample counts). The main reason for
> making it was the requirement of having two machines working in
> perfect sync, each feeding half of the speakers of a WFS system. But,
> as the patch has aged and I don't know how to port it to current sc
> (it wasn't created by us) I'm looking for alternatives now, so a bit
> disappointed that supernova doesn't do perfect sample-sync, or at
> least not in a very useful manner..
>
> cheers & thanks,
> Wouter
>
>
>> 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
>>>>
>>>>
>>>>
>>>
>