Latency issue in SuperCollider

[twistin]

Hello
I’m a bit confused about the latency issue in SuperCollider. By default, s.latency returns 0.2. This latency when I have several complex Pbinds, I get continuous delay failures and even crashes the server and the sound stops playing.
I have changed s.latency to 0.5, this improves performance but affects fadeTime which I can’t control precisely.
I have commented this before in the forum but I haven’t found any effective way to solve this problem which affects me a lot especially when doing LiveCoding. I am using a Mac M1 machine and a Focusrite Scarlett 2i2 audio interface.
I would really appreciate some help to solve the problem.
Regards

[Spacechild1]

@twistin

I have changed s.latency to 0.5

This seems excessively large. Unless you’re doing some heavy work during sequence (and thus blocking the language interpreter), the latency only has to be a few tens milliseconds.

I get continuous delay failures

What do you mean by “delay failures”? Do you mean “late” messages?

and even crashes the server and the sound stops playing.

Can you share the console output of such a crash? Or even better: a core dump?

[Wouter_Snoei]

Hi, I have these issues (late messages on “low” latency settings) too when things get complex. One thing to check is if there is anything else on your system doing mainly graphic tasks (even a finder window can already cause slowness here), as they all seem to get priority over this from the system. Also see if you have GUI stuff or for example large array calculations happening in your code, as well as postings in your post window. They all slow down SC and can cause the latency issues. And see if you can somehow optimize the amount of OSC data between server and language, for example by increasing s.aliveThreadPeriod and not do any metering etc., and perhaps also by looking into what your pbinds are actually sending (for example if you’re controlling a bus or synthcontrol, how many messages per second arrive at the server?). The general cause is OSC being too slow (network clutter), or the language being too slow to be able to handle things in time to send the message before their timestamp is due. Crashes could be caused by OSC overflow, causing messages to be lost (which in some cases I guess could cause issues on the server). There are some ways to increase the buffer size that the OS uses for this, although the default setting is already quite high (on some Linux systems this setting is ridiculously low by default). Lastly it could help if you post some code here that consistently causes these issues on your machine, so that we can compare with ours.

hope that helps! Cheers, Wouter

[dkmayer]

Also see the recommendations in this thread (some point to things already mentioned here):

Benchmarking scsynth

I cannot give a really profound answer to that, but from my experience (on OSX) SC is quite sensitive to different environmental actions. For serious work (recording e.g.) I .) close as many other apps as possible .) close as many windows and tabs as possible .) don’t do any polling, tracing or other posting of intermediate results .) avoid or reduce MIDI to a minimum .) avoid scoping .) go offline .) don’t move any windows This might sound a bit funny partially, but believe me, it is a…

And yes, if a latency of 0.5 is necessary, this indicates something really unusual. But without a minimal reproducable code example it’s hard to find.