CPU Spikes with fl.read~

Bugs
1

Summary:

I like grains :slight_smile: and with @o.green have been making a replacement for the GMU GMEM granulator using framelib. Mostly working!

I’m getting horrible CPU spikes - going from ~3% to >40%, and glitching audio playing from all other sources.

I think this is only inside an M4L environment, but still narrowing down.

FrameLib Version:

pretty sure it’s the Alpha-2.5 release - happy to try a more recent one if that sound promising.

Environment Details (Max/SC/Whatever):

macOS Mojave 10.14.6, 2.6 GHz Intel Core i7, 32 GB 2400 MHz DDR4
Live 10.4.1b1
Max 8.1.0

Steps to reproduce (Provide patch/code if possible):

There’s a folder with the patches in here: rgr.grains.zip (146.7 KB) (also a github: https://github.com/mo-seph/rgr.bufgrains)

If I open the help patch, I can set it to play a 4s grain every 2 seconds, and that’s fine (although definitely not free). If I use the MinimalLiveGranulator.amxd in the examples folder to do the same think (2000ms timing, 2.0 fill) then the cpu goes wonky. It’s generally when the grain kicks off, but not every time.

Actual Result:

CPU goes spiky and all the audio goes glitchy

Expected Result:

Buttery smooth delicious grainy goodness

Logs/Other

We (well, @o.green ) had a look with Instruments from XCode, which traced it to the fl.read~ object. We had a thought that it could be an interpolation thing - I thought that moving from default hermite to linear had helped, but it appears to still be an issue.

Audio settings in Live in case it helps…

image
image1004×1200 105 KB

2

Having looked closer at this, and talked a bit with @d.murray-rust, I’m not convinced this is a bug so much as the consequence of our naïve design, although the more pronounced badness in Live is troubling.

I’ll start a new topic about what a better design might be, but being able to spread the load more predictably so that fl doesn’t have to do all the work for big-ass grains all at once. How to achieve this in fl is another matter…

3

If you are playing always at one speed you could turn interpolation off, but I think here the time constraints are what cause the spiky processing. I’m interested in looking further when I have a moment in order to see if things can be improved here.

1 Like
4

Grand! Yes, I could see turning off interpolation and playing just at one speed, but for general purpose graining, I think that’s where approximately 0.75 of the fun is.

1 Like