Supercollider 3.13.0-rc1 / SuperDirt 1.7.3 - High Cpu Usage At Idle - macOS about superdirt

[telephon]

when I wrote "so you may not be able to observe a difference" I meant that the workaround is already in SuperDirt, so you don't need to wait and you may not notice later.

[yaxu]

I had a report of high CPU on idle for 3.13 on Linux, too.

[telephon]

OK, so we need to narrow this down a little.
As a first step, check if this is also the case with the default startup:

(
s.reboot { // server options are only updated on reboot
	// configure the sound server: here you could add hardware specific options
	// see http://doc.sccode.org/Classes/ServerOptions.html
	s.options.numBuffers = 1024 * 256; // increase this if you need to load more samples
	s.options.memSize = 8192 * 32; // increase this if you get "alloc failed" messages
	s.options.numWireBufs = 64; // increase this if you get "exceeded number of interconnect buffers" messages
	s.options.maxNodes = 1024 * 32; // increase this if you are getting drop outs and the message "too many nodes"
	s.options.numOutputBusChannels = 2; // set this to your hardware output channel size, if necessary
	s.options.numInputBusChannels = 2; // set this to your hardware output channel size, if necessary
	// boot the server and start SuperDirt
	s.waitForBoot {
		~dirt.stop; // stop any old ones, avoid duplicate dirt (if it is nil, this won't do anything)
		~dirt = SuperDirt(2, s); // two output channels, increase if you want to pan across more channels
		~dirt.loadSoundFiles;   // load samples (path containing a wildcard can be passed in)
		// for example: ~dirt.loadSoundFiles("/Users/myUserName/Dirt/samples/*");
		// s.sync; // optionally: wait for samples to be read
		~dirt.start(57120, 0 ! 12);   // start listening on port 57120, create two busses each sending audio to channel 0

		// optional, needed for convenient access from sclang:
		(
			~d1 = ~dirt.orbits[0]; ~d2 = ~dirt.orbits[1]; ~d3 = ~dirt.orbits[2];
			~d4 = ~dirt.orbits[3]; ~d5 = ~dirt.orbits[4]; ~d6 = ~dirt.orbits[5];
			~d7 = ~dirt.orbits[6]; ~d8 = ~dirt.orbits[7]; ~d9 = ~dirt.orbits[8];
			~d10 = ~dirt.orbits[9]; ~d11 = ~dirt.orbits[10]; ~d12 = ~dirt.orbits[11];
		);

		// directly below here, in your own copy of this file, you could add further code that you want to call on startup
		// this makes sure the server and ~dirt are running
		// you can keep this separate and make it easier to switch between setups
		// by using "path/to/my/file.scd".load and if necessary commenting out different load statements
		// ...

	};

	s.latency = 0.3; // increase this if you get "late" messages


};
);

As a second step you could check if this is a per-orbit load, by reducing the orbits to one:

s.reboot { 
	s.options.numBuffers = 1024 * 256; 
	s.options.memSize = 8192 * 32; 
	s.options.numWireBufs = 128; 
	s.options.maxNodes = 1024 * 32; 
	s.options.numOutputBusChannels = 2; 
	s.options.numInputBusChannels = 2; 
	// boot the server and start SuperDirt
	s.waitForBoot {
		~dirt = SuperDirt(2, s); 
		~dirt.loadSoundFiles; 
		~dirt.start(57120, [0]);   
		
		
	};
};

If this is the case, the next step then would be to find out which of the global effects cause the problem.
This can be done by commenting in step by step the different global effects (this works on the fly).
We assume you have only one orbit (as above).

(
~dirt.orbits.first.globalEffects = [
//			GlobalDirtEffect(\dirt_delay, [\delaytime, \delayfeedback, \delaySend, \delayAmp, \lock, \cps]),
//			GlobalDirtEffect(\dirt_reverb, [\size, \room, \dry]),
//			GlobalDirtEffect(\dirt_leslie, [\leslie, \lrate, \lsize]),
//			GlobalDirtEffect(\dirt_rms, [\rmsReplyRate, \rmsPeakLag]).alwaysRun_(true),
			GlobalDirtEffect(\dirt_monitor, [\limitertype]).alwaysRun_(true),
		];
~dirt.orbits.first.initNodeTree;
)

[gus74vv]

Hi Julian. I proceeded as you point me out above, first, booting superDirt with the default startup... The load on the cpu remains high... Then, when booting with a single orbit, obviously the charge dropped significantly by 80/90%.
Finally, I booted again with the default startup, but this time with the global effects disabled in DirtOrbit.sc, and I activated them one by one to check the incidence that each one has on the cpu load. Each one of them adds a significant load on the cpu that fluctuates between the following values:

Monitor: 4 - 6%
RMS: 1 - 3%
Leslie: 8 - 15%
Reverb: 6 - 18%
Delay: 3 - 7%.

all values taken at idle

I reinstalled supercollider 3.12.2, and everything works normally. Maybe the problem is due to the fact that version 3.13 is a release candidate. I will check again later with a final version.

Thanks.

[Etol1LC]

I had the same issue on Linux. Went back to 3.12 as Alex suggested. Possible bug in SC version 3.13. Il mer 16 nov 2022, 21:43 gus74vv ***@***.***> ha scritto:

…

I updated Supercollider to the latest version (3.13.0-rc1), and now when I boot superDirt, my cpu has a constant 35~45% load at idle, without even using TidalCycles, when in the previous version (3.12.2 ) , cpu usage was around 0.3% also at idle. macOS 10.14.6 SuperDirt 1.7.3 TidalCycles 1.9.2 Supercollider 3.13.0-rc1 -- My startup file: `s.reboot { s.options.numBuffers = 1024 * 256; s.options.memSize = 8192 * 32; s.options.numWireBufs = 128; s.options.maxNodes = 1024 * 32; s.options.numOutputBusChannels = 2; s.options.numInputBusChannels = 2; // boot the server and start SuperDirt s.waitForBoot { ~dirt = SuperDirt(2, s); // load mi-ugens.scd synthdefs load("/Users/gustavo/Library/Application Support/SuperCollider/synthdefs/mi-ugens.scd"); load("/Users/gustavo/Library/Application Support/SuperCollider/synthdefs/x_sine.scd"); // end load mi-ugens.scd synthdefs ~dirt.doNotReadYet = true; ~dirt.loadSoundFiles; ~dirt.loadSoundFiles("/Users/gustavo/Documents/sndfiles/"); ~dirt.loadSoundFiles("/Users/gustavo/Downloads/tidalSMPL/ *"); ~dirt.loadSoundFiles("/Users/gustavo/Downloads/spicule-master/extra-samples/* "); ~dirt.start(57120, 0 ! 12); // optional, needed for convenient access from sclang: ( ~d1 = ~dirt.orbits[0]; ~d2 = ~dirt.orbits[1]; ~d3 = ~dirt.orbits[2]; ~d4 = ~dirt.orbits[3]; ~d5 = ~dirt.orbits[4]; ~d6 = ~dirt.orbits[5]; ~d7 = ~dirt.orbits[6]; ~d8 = ~dirt.orbits[7]; ~d9 = ~dirt.orbits[8]; ~d10 = ~dirt.orbits[9]; ~d11 = ~dirt.orbits[10]; ~d12 = ~dirt.orbits[11]; ); }; s.latency = 0.3; // increase this if you get "late" messages` — Reply to this email directly, view it on GitHub <#277>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AL5J2RWTQ76UO2XJLUJJ4ZTWIVBPPANCNFSM6AAAAAASCUWTMY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[telephon]

good!

each one of them adds a significant load on the cpu that fluctuates between the following values:
...
all values taken at idle

OK, so either they are not paused or the UGens are less efficient.

To distinguish the two cases, could you check if using the effects changes the level or not?

[Etol1LC]

In my case even the simple d1 $ s "bd" was giving me loads of Xruns. But adding effects was almost freezing the audio. I have switched to an earlier version of SC so I can't check right now, to tell you the actual values, but it was between 45% and 50% when firing up SuperDirt, and between 55% and 70% when playing sounds, with or without effects. For the records, I was using SC 3.13.0, built from source, on Linux Mint. Cheers. Etol Il giorno gio 17 nov 2022 alle ore 16:55 Julian Rohrhuber < ***@***.***> ha scritto:

…

good! each one of them adds a significant load on the cpu that fluctuates between the following values: ... all values taken at idle OK, so either they are not paused or the UGens are less efficient. To distinguish the two cases, could you check if using the effects changes the level or not? — Reply to this email directly, view it on GitHub <#277 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AL5J2RWP5MNMWK6V3NXZ2T3WIZIPJANCNFSM6AAAAAASCUWTMY> . You are receiving this because you commented.Message ID: ***@***.***>

[gus74vv]

reinstalled 3.13, and in my case, triggering some samples and synths through Tidal and applying some of the global fx (room, delay, leslie) doesn't seem to add a significantly higher load on the cpu. Only about 2 to 10% on the more complex patterns, on top of what we have on idle.

[telephon]

OK, here is another test. When SuperDirt is on idle, the code below should post one set of comments, but not continuously. If it posts continuously, we know that the global effects are not paused.

(
var numChannels = ~dirt.numChannels;
(1..SuperDirt.maxSampleNumChannels).do { |numChannels|
	SynthDef("dirt_global_poll" ++ numChannels, { |dryBus, effectBus, gate = 1, restart = 1|
		var signal = In.ar(dryBus, numChannels);
		effectBus.poll(label: "I am not paused, sorry.");
		DirtPause.ar(signal, 1);
	}, [\ir, \ir]).add;
};

~dirt.orbits.do { |x|
	x.globalEffects = x.globalEffects.addFirst(GlobalDirtEffect(\dirt_global_poll, [\restart]));
	x.initNodeTree;
};
)

[gus74vv]

ok, that flooded the post window continuously with the message: "I am not paused, sorry" :)

Edit: In SC 3.12.2 it posts the same message but only once.

[telephon]

Ah very good, so we are closing in.

Now, when you try this one:

(
{
	Silent.ar.poll(label: "I am not paused, sorry.");
	PauseSelf.kr(Impulse.kr(0));
}.play
)

Does it also flood you?

[telephon]

Additionally, you could check out this branch:
https://github.com/musikinformatik/SuperDirt/tree/topic-test-pause-change
and see if it solves the issue.

There, I do the initial pausing of effect synths differently, this is a workaround, but not a hack.
Even if it solves it, we should try and find out what is source of the problem.

[gus74vv]

Ah very good, so we are closing in.

Now, when you try this one:

(
{
	Silent.ar.poll(label: "I am not paused, sorry.");
	PauseSelf.kr(Impulse.kr(0));
}.play
)

Does it also flood you?

Yes. It floods the post window with the same message....I'll try the workaround and report back later.

*Edit: Already tried that branch and I can confirm that it totally solved the problem!. 0% load on cpu at idle.

Thanks Julian!

Cheers!

[yaxu]

Fix here if anyone's ready+able to test it out! supercollider/supercollider#5914

[telephon]

The change merged here #278 should have fixed it on the superdirt side, so you may not be able to observe a difference.

[yaxu]

@gus74vv or anyone watching, are you able to confirm that this is fixed? there's a binary available now: supercollider/supercollider#5910 (comment)

[dyfer]

As @telephon mentioned, the linked SuperCollider fix would need to be tested with the version of SuperDirt before #278 was merged.