PartConv Ugen initial CPU spike

Questions
1

First time I use PartConv in a synth after I have booted the server I get an initial CPU spike of 200-300% and a glitch in the audio. This only happens once, and not again even if I use a different impulse response. But, it happens again if I use two instances at the same time, but again only once. Any thoughts on what might cause this and how to prevent it? Is it some initial allocation of resources going on? The buffers are already loaded and prepared, so that is not it.

I’m on SuperCollider version 3.12.2 and a Macbook Pro M1, but this also happened on my previous Macbook Pro Intel.

2

Could you posted a minimal example please?

3

Don’t know how to do that without supplying the IRs somewhere. The IRs are quite long, like 10 seconds of stereo reverb. The buffers are mono (one for each channel). Imagine that the buffers are loaded into the variables, then it’s not more complex than this:

// WON'T WORK since buffers are nil
{
	PartConv.ar(Saw.ar(LFTri.kr(0.2).range(100, 200), 0.05), 2048, [~bufL, ~bufR]);
}.play

Works fine except for the explained initial first time CPU peak.

4

This gives me better performance. I don’t think you are supposed to pass arrays into PartConv.

{
	var stereo = SinOsc.ar(LFNoise2.kr(0.3!2).range(200,400));
	var reverbed = [ [~bufL, ~bufR], stereo].flop.collect{
		|a|
		PartConv.ar( a[1], 2048, a[0]);
	};
}.play
5

Thanks, but this doesn’t make a difference for me performance wise, I get the same result. I think the array will just multichannel expand as usual?

Is there some kind of lazy resource allocation going on? There’s always an initial cpu peak when I make more instances.

6

That’s correct – arrays aren’t the problem.

The PartConv source code doesn’t hang onto resources after its destructor is called (when the synth is freed), so I don’t think it’s happening in our code.

I wonder if it’s an OS-related memory paging thing? (I don’t observe a glitch or spike in Linux.)

hjh

7

Ahh, yes there was a typo in my code… woops.

well doubling the fftsize halved the cpu usage and I didn’t get any spikes.

8

Yes, I have a suspicion that it can be OS-related, but that’s way over my head. My hope was that it could be related to maybe ServerOptions settings, but my only workaround at the moment is just to silently start and stop a few instances before I make sound to avoid the glitch. As mentioned the IRs are 10 seconds long. For shorter IRs it seems the same thing is happening, but then the CPU can handle it without any glitch.

I’ve been digging into this a bit now and made a loopback in the soundcard to detect server glitches and track cpu usage, and it seems that these spikes usually appear whenever I use new types of ugens, especially the ones related to memory and buffers, like PartConv, BufRd, VOsc, long delays etc. Anything that limits cpu usage like blockSize and hardwareBufferSize also makes the spikes smaller and at some point they go undetected. But the initial peaks are way higher than the normal peaks when the synths are running.

So it seems this is not a PartConv problem after all.

9

Does memoryLocking make a difference?

10

Unfortunately no, doesn’t seem like it. But it makes sense, would be awesome if that solved it, thanks for the suggestion. Looking at the activity monitor the scsynth process seem to have the same amount of both physical and virtual memory with memoryLocking on an off (I’m rebooting the server, of course). Don’t know if that means that the memory request fails.