[osc] mysterious clock drifting

[felixroos]

Under some unknown circumstances, the osc messages will arrive late in supercollider.
On lowend machines, this seems to happen more easily, though it could be a separate problem.
There seems to be some clock drifting going on, most likely that osc uses the system clock and strudel uses Date.now (on page load) + audio time since since page load. So far, I was only able to get late messages after a longer time of inactivity without refreshing the repl. after a refresh, the clocks are aligned again.

The clock drifting could be avoided if .osc would use performance.now instead of audio time.

[bwagner]

This happened on a MacBook Pro with chip Apple M1 Max, memory 32 GB running Ventura 13.2.1. Drifting started after around 45 seconds.

[felixroos]

same drifting seems to happen with midi too. the midi clock fell ~15ms behind after roughly a minute. Midi uses WebMidi.time which is based on performance.now() and the scheduler uses AudioContext.currentTime, so these clocks are probably also not running in sync

[felixroos]

the scheduler is clock agnostic, so it might make sense to test what happens when it uses performance.now(). My guess is that midi will run perfectly but web audio will get out of sync..

[felixroos]

this could be the solution for the clock drift: https://developer.mozilla.org/en-US/docs/Web/API/AudioContext/getOutputTimestamp

[felixroos]

fixed with #666

[felixroos]

this is not fixed.. it seems to be related to accumulating float rounding errors. this seems to only happen for certain cps numbers: .5 1 2 is fine, while .75 is not.. The problematic bit is most likely:

const begin = this.lastEnd;
this.lastBegin = begin;
const end = round(begin + duration * this.cps);
this.lastEnd = end;
const haps = this.pattern.queryArc(begin, end);

the calculation duration*this.cps does not have perfect precision, so each tick the error is accumulating, creating a larger and larger drift as time passes. this should be fixable with fractions

[yaxu]

It doesn't necessarily need fractions, you can avoid accumulating rounding errors with a calculation like:

begin = lastend
end = time_of_cps_change + (number_of_frames_since_change * time_per_frame)

[jarmitage]

workaround

const loopAx = register('loopAx', 
  (l, pat) => pat.loopAt(l).chop(l*8).legato(1).mul(speed(0.99))
);