CPU spike when creating a new loop (creating a new loop)

[rconstanzo]

As reported to me by Bernt Isak Wærstad (@berntisak), when starting a new loop (e.g. clearing an existing loop), you get a short CPU spike as karma~ clears the buffer~.

I don't think this was noticeable in Max due to the averaged CPU usage, but it's more visible in Live/M4L.

Attached is a video showing the issue.

karma-CPU-spike.mov.zip

[berntisak]

Have you had a chance to look into this @rconstanzo ? Even with very short buffer sizes it still happens every now and then (a bit too often)

[rconstanzo]

Nothing recent, though this is definitely on the list with a 2.0 rewrite. Basically when you start a new loop it completely zeros out the whole buffer~, which can jam up the CPU momentarily.

I've not tried this out, but maybe try a defer or deferlow before the record message? (I've run into related issues with SP-Tools in M4L/Live as things happen in audio interrupt there, and heavy processes can briefly cause an audio hiccup.)

[berntisak]

Ah, thanks - I'll try the defer to see if it helps. I'll report back here if I feel I got some answers/solutions

[rconstanzo]

I don't know/remember how that is handled once it gets inside karma~ so it's possible that the thread that comes in is irrelevant, but hopefully that can act as a temporary bandaid.

[berntisak]

Found some time to check it out today and neither defer or deferlow does any difference unfortunately.

[berntisak]

Since the defer didn't work, I had a poke around the code and managed to reduce the spike quite significantly! Instead of using a for-loop to zero out (line 1652-1665), I tried using memset:

memset(b, 0, sizeof(float) * bframes * rchans);

It seems to be the bandaid I need for now at least - even a 1min long buffer only get a small spike on the Live track CPU meter. I'm not at all an expert on C, so don't know if there are any downsides to this solution, but could maybe be a quick fix for now as I see other alternatives of zeroing in chunks or zeroing while writing (or switching between two buffers or something) would involve a much more substantial reworking of the code

[rconstanzo]

Ah great!

Yeah, I don't think that was done in the most efficient way before. There may be an even better way(?) to do this, so it happens in a low priority thread (to not spike Live at all, which always run with the scheduler in audio interrupt).

Ideally it wouldn't need to zero at all and you can just record "over" what's there, but because you can setloop and things like that, you can play beyond bits of the buffer~ that have been recorded into, meaning you could end up playing garbage.

[berntisak]

I think either of those ways probably would be the best way to go about it, but would involve a lot more rework I guess. But for now, this works at least a lot better than the previous for-loop solution and makes it usuable for buffers longer than a few seconds. I could set up a PR if you want to include it. Or you could just add the change yourself of course - just one line after all.

[rconstanzo]

The next significant update will be a 2.0 rewrite, so you're welcome to do a PR but I likely won't do another compile before then (especially since I rely on others to do the build, including windows which always ends up being a pita).

[berntisak]

Allright. I'll see if I remember how the PR system works again. Since I've already done a build of the external for Mac, I can at least share it here for anyone else who might be interested:

karma~ for Mac with reduced CPU spike on record

Feel free to put this build anywhere else where it could be available for more people