Re: supernova sample-based scheduling bug?

Hi Christof,

> Op 20 mei 2021, om 15:58 heeft [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] <mailto:[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
>>> 
>>> 
>>> 
>>