"non(?)-issue" system sizing, multi-threading, documentation

[elpeh]

Hello,

with no "Discussions" section enabled, a kind of documentation issue, but also related to #39

• build documentation in general could be expanded
• Plugins and standalone version are building on RaspberryPi 5 (Raspbian OS), I tested the standalone version. It seems to work fully, but "noise" artefacts are being generated with either/and too many sounding notes (clusters/fast arpeggios), too many stops active, too much convolution reverb. Both with internal or USB-DAC audio. Shown CPU usage is not approaching 100% though. This leads to:
• Of course code can be analyzed, but could you tell if the relevant code paths are multi-threaded? Apart from buffer size (which had less effect than I tought) do you have further optimzation tips?
• Running Intel linux, what "do you think" which CPU is "safe" with the default organ definition, low latency, complex convoltion.. any tests/experiences? (convertible may be nice for a planned usage)

Thanks, Lutz

[Archie3d]

Hi,

• Could you elaborate on issues you've faced during the build? This is a pretty straightforward cmake project, unless you have a particularly weird target.
• I have not put any effort into building or testing this on RPi. Have you tried disabling the reverb completely (move the slider to the left)? I've run the plugin on 2nd generation iPad (very old) and it was working OK (without the reverb), so don't see why it could not work on RPi (without the reverb). What was the buffer size you were using?
• The reverb is multithreaded with one asynchronous thread, using more threads is not a good idea since when running with other plugins in a DAW this will degrade the overall performance. Wavetables generation (on start or tuning change) is also multithreaded. Apart from this, there are no any additional treads running.
• I've put no SIMD optimization for ARM processors (only for Intel), and Mac machines are powerful enough to care about optimizing for Apple Silicon. I suppose RPi would suffer with convolutional reverb. An alternative would be to have an algorithmic reverb (which is what the original Aeolus was using).
• I have not tested extensively various PCs, but any modern CPU should do just fine. I am running i9-9900K, and see no significant CPU load even with many stops enabled and the longest convolutions.