Instantiation causes xruns

[madskjeldgaard]

Hi all

Thanks for your amazing work!

I noticed a problem lately that I think should be addressed somehow.
When instantiating Flucoma's UGens in SuperCollider, xruns are caused on Linux (and perhaps other things happen on other systems on instantiation, I dunno). Even with low cpu usage and basically nothing else going on. This is seen quite clearly when using Flucoma-UGens in a live coding context in NodeProxy land. As an example, an Ndef that has fadeTime at 1. Every time the Ndef is reevaluated, it will create a copy of itself and slowly fade from the past to the future version of the synth. When using Flucoma's Ugens this is where the spikes/dropouts are clearly heard/seen:

Ndef(\yo, {  FluidHPSS.ar(WhiteNoise.ar)}).fadeTime_(1);

Try reevaluating that a couple of times.

My suspicion (which I haven't been able to fully prove yet, sorry) is that this is caused by allocation in the C++ code. Looking through the source code for the UGens I don't see any use of the recommended RTAlloc method for reserving memory from the realtime memory pool and so I suspect this is being done with STL containers or something, which may be the cause of the problem. As I said, this is only a suspicion by now but perhaps this can be a pointer to help you bug hunt this.

This SuperCollider help file has more info on avoiding STL containers.

Thanks!

[weefuzzy]

Many Thanks @madskjeldgaard,

Very useful to have a case demonstrating this being problematic.

Yes, the problem is likely to be allocations, and this is something we intended to address, although I'm afraid it won't be quick because the whole thing is pretty complex. There are some issues in the generic wrapper we made for the SC objects, and these are (largely) addressed in a forthcoming, very extensive, update to this repo alongside the second wave of objects. Basically the wrapper has been re-written (more than once!), and is generally better about using the SC pool for allocations on the RT thread. But still not perfect.

The much more complex changes to make are further back in the stack, where the algorithms live. Some of these will be curable by using an allocator class (where we do use the STL). However, the Eigen library we use for linear algebra things is a tougher nut to crack, both because it doesn't give the option of using a custom allocator and because it can sometimes cause temporaries to be allocated in expressions. There are ways around both of these, but it will be a longer term effort, I'm afraid. We will, at least, be in a position to properly review once the forthcoming merge is complete.

We were aware of the SC advice against using the STL (honest!), but opted to get something working to start with (particularly given that we target multiple hosts), and broach the allocation issue once we knew the shape of things. Personally I've always regarded that injunction as being overly blunt: there's nothing especially incompatible about the STL containers, provided one can use a custom allocator.

[madskjeldgaard]

Thanks for the quick and thorough response. It sounds like some of this will be addressed in the upcoming release but then perhaps the Eigen lib / complex stuff which sounds unlikely to be ported to SuperCollider's RT alloc system, maybe these ugens affected by the latter should have some info on this in the documentation. So maybe documentation could be a sort of solution ?

Admittedly, the usecase of livecoding/-instantiating is probably just not a recommended way of working with these objects (and probably also rare).

Anyway, thanks again!

[weefuzzy]

I should have mentioned that for most objects it's possible to at least mitigate the costs of instantiation by turning down the seldom-used max<Something> parameters where available. In the specific case of HPSS, it allcotaes memory for its FFT, but also for two median filter banks. If you're happy enough with the sound of the default values for these parameters, then the maxFFT, maxHarmFilterSize and maxPercFilterSize can all be reduced quite a bit.

[weefuzzy]

Re: documentation, you are right – I guess it was the shame :-) Longer-term, we do intend to deal with all of these, including the Eigen ones: we can refactor the Eigen stuff to use memory buffers we control and to avoid temporary allocations, albeit at the possible cost of readability.

[weefuzzy]

@madskjeldgaard I've just merged PRs into core and here that should hopefully go some substantial way to addressing this: all the algorithms have been reviewed, and anything that touches the audio thread on SC should now be using the pool allocator (although I've probably missed some!).

The current nightly builds should include these changes (or just pull from dev for the bleedingest edgiest)

[madskjeldgaard]

@madskjeldgaard I've just merged PRs into core and here that should hopefully go some substantial way to addressing this: all the algorithms have been reviewed, and anything that touches the audio thread on SC should now be using the pool allocator (although I've probably missed some!).

The current nightly builds should include these changes (or just pull from dev for the bleedingest edgiest)

Brilliant work. Thank you so much!

[salkin-mada]

Fantastic!