Today, I was verifying the behavior of LinkClock vs Max and found that we may need to change our recommendation:
- Current:
LinkClock.new.latency_(s.latency). - Probably better:
LinkClock.new.latency_(s.latency - audioDriverLatency).
I say probably better because, at least in Linux, LinkClock timing seems to vary somewhat depending on NTP behavior. I’ve seen problems with that when launching SC shortly after waking from sleep. If sclang is started a relatively long time after waking (not sure how long, I guess 10-30 minutes should be enough) then the behavior is consistent.
If I run Max’s [link.beat] and Pd’s [abl_link~] external together, they are in good sync.
If I add LinkClock.new.latency_(s.latency) to that, it’s late.
Reducing the clock latency (but not server latency) by roughly the audio driver’s period sounds much better.
Can anyone else confirm? If so, I’ll update the docs.
BTW it would be nice if sclang had access to the actual hardware buffer duration, maybe by querying the server. AFAIK in Mac and Windows you can request a hardware buffer size (but I’m not sure you have a guarantee of getting that exact buffer size). In Linux, audio hardware configuration is JACK’s responsibility; SC has no control over it. So s.options.hardwareBufferSize is not a sufficient interface for this. (/status.reply includes “nominal” and “actual” sample rates, but not buffer size.)
hjh