ive run into a couple issues while experimenting with the sickoSampler module.
1- i have a basic patch that runs 4 instances of that module. the total mb of the 4 16b/48khz.wav stereo files im using totals around 18mb on the sdc. the patch without any samples loaded uses 42mb/278 - 15% of the system’s ram. when i hit play(system set to 48/128), the module pauses for a while while loading those 4 samples into ram and then the system shows 244mb/278 88% of the system’s ram in use. im curious why are we seeing such a large use of ram when the .wav files are initially only 18mb altogether on the sdc?
i have another patch which runs 8x sickoSampler modules. i can only run this module when the system is set to 24khz. otherwise it freezes the mm and i have to reboot(ram issue?). the cpu at 24khz with this patch is around 40%. with no samples loaded the patch runs fine at 56%. however it freezes/crashes the mm trying to run it at 48 with the samples in the patch, so is this a ram overload issue? at 24khz, with this 8x patch, the system shows only 196/278MB 71% ram used. the total file size of all 8 samples together on the sdc is only 28mb. again there’s that huge jump when the samples are loaded into ram on mm. im curious why this is? and also im curious why this 8 samples patch would ultimately use less of the systems’ ram than the 4x patch mentioned above?
2-when the 4x patch is running and i switch the system from 48 down to 32 or 24, the mm freezes/crashes. im assuming this is a ram issue. not sure if that’s on dan’s end or if it’s something within the module itself @danngreen - maybe we could use a ‘ram limit hit’ pop up like we get with the cpu overload, instead of the module crashing?
3-also im noticing some audio glitches during sample playback when the system is set to 512. switching to 128 buffer seemed to fix the issue. this does not happen all the time so i can’t say yet what i was doing to make these playback glitches occur. it was in the 4x patch, and it was only occurring with one of the sickoSampler modules, not all of them.
fyi if you try and run those patches above, im now noticing a bug with the airwindows module, where no sound will pass through it unless you go actions>initialize the module. will report that elsewhere
I’ve not tried these modules but just to note that in my own sampler module tests playing back a sample has very minimal minimal cpu cost. I’m running 2 instances of one stereo sampler and 1 of another at 48k with about 25 meg of samples loaded total and it shows about 25% on the cpu meter. I’m doing a 6 point spline interpolation to the samples on playback in two of the instances (since it’s phaser driven) and I’m doing no interpolation in the other (the caveat being that I’m allowing samples at the same sample rate the MM is running at and there is no speed/pitch control just a gate to play the sample or not).
There’s a lot going on in their process loop with all the (cool) resampling, interpolation, adsr etc… features that the modules have so it’s a bit tricky to know at a glance exactly what is expensive there, and obviously it’s doing a hell of a lot more than my modules, but tldr is that I don’t think sample playback per-se is that cpu intensive on the MM.
The issue to do with changing sample rates could be to do with the fact it looks like the module resamples everything in memory which is pretty expensive (and maybe uses too much ram?)
What I have seen in my own test is the issue with block sizes. At 512 I have the same issue (I’ve asked about it here Optimising sample playback routine for block size but not had a reply yet). I believe it’s a buffer filling up in the background, or since I’ve only had it happen in recent builds maybe it’s a new async call happening somewhere which is causing some issues with the audio thread. You can really tell on loops because the loop will play successfully, then sound weird, then go back to being fine at regular intervals, which definitely feels like a background process is causing the issue.
That definitely sounds weird, I’ll see what I can find. But I will say that the RAM usage meter is complicated – there are multiple stages of memory allocation, so it’s not a pure 1:1 measurement when comparing patch. The amount of free RAM might not go down even if the patch is closed and memory is freed because the allocator is allowed to hold onto memory chunks if it wants to.
To do a pure test, set a patch to be your startup patch and then power cycle. Immediately check the RAM usage. Then open another patch, let it play for a couple minutes (so that it’ll be the start up patch) and then power cycle and immediately check RAM usage. Obviously make sure the same plugins are auto-loaded or else that could throw off the numbers.
so after trying all the patches as startup with and without samples, after power cycle, im seeing mostly the same ram usage numbers as i listed above:
4x sickLooper (no samples loaded) = 44/278mb on mm
4x sickoLooper (samples loaded, the 4 wav files are only 18 mb on sdc ) = 220/278mb on mm
8x sickLooper (no samples loaded) = 44/278mb
8x sickoLooper (same 4 wavs as 4x patch + 4 extra = 26mb on sdc) = 196/278mb on mm
a lot of ram spike is happening when the samples are loaded. im curious: is the sickoSampler just allocating a max size swath of ram for each sampler instance regardless of how small the initial loaded sample is (instead of allocating for the actual size of the loaded wav)? or perhaps @sickozell is there an option on the module to help remedy this?
really would love to be able to run the 8x patch at 48(sounds way better than 24) as i adore the sickoSampler- has a lot of great features! ive even tried a 6x patch too but it won’t run unless we’re at 24khz.
that sounds v promising! i’m curious @twhiston which sampler module are you using? i’d love to try it out as well…
I’m afraid they are some modules I’m working on and are not public yet, mainly as they are very basic and have a tonne of rough edges and caveats. So I’m afraid you can’t easily try them right now, but once I have them more sorted I’ll release them and all the other modules I’ve been making for my live setup.
Out of interest are the samples you are playing at the same sample rate as the MM is set to? The SickoSampler plugin does some resampling on load which uses some temporary buffers if your samples rate isn’t the same (or double) the engine.
From a quick look at the code it appears that if the sample rate is double the engine rate it loads it directly, if the sample rate is the same as the engine it does some interpolation and creates an extra value per sample per channel (thus doubling the capacity needed), and if it’s anything else it does a full resampling.
At the end of that full resampling it looks like it clears the temp buffer but it doesn’t do anything to reclaim that memory so it might be a side effect of this which is contributing to the ram usage you’re seeing. @danngreen do you know if shrink_to_fit would free the vector memory on the mm? Or is it better to reassign like v = std::vector(); ?
yes, im using 48/16 bit samples (system set to 48). i noticed when i save the .wav from the sickSampler back onto disc, it’s a 48/32b file. the total of all 4 of my 48/16 samples = 18.5mb on the sdc. double that for 32bit and we have 37mb. if i can run the empty no samples patch at startup and only see 44mb used, add 37 to that, it should read out around 81mb. but for whatever reason, it is using upwards of 220mb instead.
is sickoSampler resampling to 192khz/32bit? that would mean my initial 18.5mb would turn into 148mb. but add that to the initial 44mb, still that wouldn’t reach the 220mb im seeing… color me confused
Could the problem be using the clear() function?
I’m not a good C++ programmer, but I can try to replace it with:
vector().swap(tempBuffer[LEFT]) ;
vector().swap(tempBuffer[RIGHT]) ;
I think you need to either do what you suggested (swap the vector into a temporary) or shrink_to_fit() the temp buffer after you clear it (but reclaiming the memory is not guaranteed in this case apparently either!) I guess it would be worth testing on the MM to see which works best.
Another way, is you can make the temporary buffer vector a local function variable so that when the function ends, the memory will get released. Just copy its contents to the playBuffer before then. The time it takes to copy will be a small fraction of the time it takes to load from disk.
Also, when the patch loads, each module is loaded one at a time. So if a patch has 4 samplers in it, and each one needs 50MB temp memory but only 25MB run-time memory, then the peak memory usage will be 125MB, since only one module will have the large temporary buffer at a time. This is assuming the file loading happens in the constructor or on the first time process() is called.
so far .10 is still showing the same ram use as listed above with .8 = 220mb taken up with the 4x samples(system set to 48) and 196mb ram via the 8x samples patch(system set to 24khz)
just so i know how it’s working, so if the system is set to 48khz, does the sickoSampler resample to 96khz/32bit size in ram (the samples im using are 48khz/16)?
the sickoSampler is still one of the best featurewise imo, but for now at least until the ram thing is fixed or the sts shows up(w disc streaming), canard is certainly a great alternative. especially for longerish loops.