Lessen CPU load on long note release times

[muziker]

Bug Description: Fast apreggiation on wavetables causes huge cpu spike

Surge Version 1.8.HEAD.9de9336 LV2

Reproduction Steps:

1. select a patch that uses wavetables
2. raise EG-release to maximum
3. do a fast arpeggiation
4. observe cpu load spike exponentially
5. crackling sound as load hits 100%

Expected Behavior: long release times with less cpu load.

Computer Information (please complete the following information): It's a linux

Additional Information: Really not sure how this gets solved, but i'd love to find out. Additionally, it could also be due to I/O based off of streaming wavetable data from disk. When using not wavetables, this behaviour is somewhat less pronounced

[baconpaul]

So: it gets solved by lowering the release time, lowering the poly count so voices get killed, using a smaller wavetable, choosing a less cpu intensive filter, or lowering unison count. Or by purchasing a more powerful computer. It all really depends on the particular patch.

We've profiled these things pretty carefully. I'm sure there is more to be squeezed out, but its maybe integer percents from optimization not orders of magnitude. If you need orders of magnitude you need to use the synth differently, is our experience.

Do you have the particular patch?

[baconpaul]

but always welcome users using dtrace and finding hotspots! If you are an experienced programmer / instrumented / optimizer we can definitely do better and could definitely use help!

[muziker]

No particular patch, i was randomly going through the presets and doing the arpeggiating ambient brick technique, and discovered the spikes. I probably need to use different to lower the cpu load.

[baconpaul]

So between 1.8.0 and 1.8.1 Jacky did a bunch of work to optimize his ambient patches. But we also upped default poly count to 16 which can run CPU pretty hot.

I think it really depends on the patch and the technique it uses. But if you have a patch you really like, Jacky and I basically fond that lowering unison and release times are big helps and are sonically pretty neutral.

If you found a particular patch that runs you out of CPU we would be happy to look and see if it is something else, though. I haven't profiled all 2000 factory patches! (but consider it every now and then)

[muziker]

How do you profile surge for hotspots anyway?

[baconpaul]

My best results I use instruments, which is the macOS wrapper on dtrace, and run it in a lightweight host (hosting AU).

If I were on linux, I would do the same with dtrace and carla

I have also built the headless wrapper which is more than capable of playing a patch and profiled that on the command line.

[baconpaul]

for valgrind for instance, which runs better on linux than mac, i build headless and valgrind it on lin. https://github.com/surge-synthesizer/surge/blob/main/doc/Developer%20Guide.md#linux

[muziker]

I'll have to relook dtrace again for this

[mkruselj]

Also, wavetable data is not streamed in realtime, it's completely in memory.

This is not really a bug. Certain oscillators do need more CPU than others, and WT oscillator is one of them. Especially at higher unison count.

[baconpaul]

So @muziker if you are planning on attacking surge with dtrace, I am just about to merge a helpful little program to headless. Basically if you build surge-headless and run it as follows:

surge-headless --non-test --performance ~/Documents/Surge/Test/DPWONE.fxp 0

it will load that patch, hold a middle C, and play forever at 48k showing you how much of a second it took to render 1 second worth of audio.

You can start this then attach dtrace or whatever and see the profiling output.

Once I merge #3926 should be in the mainline.

h2h.

[mkruselj]

Kinda think we should close this one. Everything has been mentioned - longer release times will need more CPU due to tails overlapping which shoots polyphony up with fast arpeggiating... and the solutions were already mentioned.

[baconpaul]

Agree. I also pushed some optimizations to some oscillators since this comment