11-06-2019, 02:59 AM | #1 |
Human being with feelings
Join Date: Feb 2019
Location: Zürich, Switzerland
Posts: 8
|
Reaper using only one core?
I'm semi-new to Reaper and working on a small project for exercise (basically only MIDI and software synthesizers). The project got bigger and got more tracks until, at some point, Reaper started to stutter. I didn't think much, I mean, this is bound to happen at some point – although I was a bit surprised, because my computer basically still looked close to idle, mostly twiddling its thumbs and waiting for work.
Anyway, I froze some tracks to fix the stuttering. That's when I realised: Reaper was using 12% CPU while rendering multiple independent tracks. I've got a 4 core CPU with hyperthreading (→ 8 pseudo cores), so 12% CPU usage is what you get when using one “core” 100%. When rendering 8 or more independent tracks, I'd expect 100% CPU usage (or 800% counting per core). Thinking back, I've never seen Reaper using more than 12%. I restored the frozen tracks to check – Reaper was stuttering using 12% CPU. I understand that audio is naturally a very serial thing, but there's still much room for parallelisation, at least at track level. But it sure looks like Reaper is never using more than one core. That's not possible, is it? I just can't believe that Reaper actually isn't capable of using multiple cores. I must have missed something, it must be a configuration issue. Any ideas on that?
__________________
openSUSE Leap 15.1 i7-6820HQ 2.7GHz (4 Cores, 8 Threads), 32GB RAM |
11-06-2019, 06:55 AM | #2 |
Human being with feelings
Join Date: Feb 2007
Location: Oulu, Finland
Posts: 8,062
|
Are they truly independent? Are folders, aux sends/returns etc involved? Could there be a plugin that forces the processing to be serialized? Is using multiple threads/cores enabled in the Reaper preferences in Audio->Buffering? (Reaper auto-detects the number of used threads by default, maybe that went wrong on your system.)
__________________
I am no longer part of the REAPER community. Please don't contact me with any REAPER-related issues. |
11-06-2019, 10:20 AM | #3 |
Human being with feelings
Join Date: Feb 2019
Location: Zürich, Switzerland
Posts: 8
|
Exactly the setting under Audio → Buffering is what I was looking for. It was on auto (showing 8 in the disabled box), I tried setting it explicitly to 8, to no avail.
There are sends and folders involved, but I'd say 4 tracks are truly independent (no receives → midi → (fx) → instrument → fx → out without any sends), one of them is in a separate top-level folder. I don't know about the plugins. There were some scripts I wrote myself that I just deleted (no need anymore), a few unsuspicious packages from ReaPack (Various_functions, LearnManager, Midi convert to CC). Then there's SWS which has no official Linux build. I removed it temporarily, same thing. It was freezing 8 tracks at 12% CPU, that should have been doable with at least 4 threads, 2 at the very least if it sees dependencies where there are none. But it's not just about freezing. Of course, I don't constantly look at Reaper's CPU usage, but I really never saw it using more than these 12%. Also played with the "v4.x worker thread scheduling" setting, nothing.
__________________
openSUSE Leap 15.1 i7-6820HQ 2.7GHz (4 Cores, 8 Threads), 32GB RAM Last edited by Abnaxos; 11-06-2019 at 10:35 AM. |
11-06-2019, 12:50 PM | #4 |
Human being with feelings
Join Date: Sep 2018
Location: Colorado
Posts: 429
|
I do not know if the reading is a 'Globalized' reading (or for individual cores) I think you have to use 'SMP'Machine instead of 'UP' Machine...The mpstat command can be used both on SMP and UP machines, but in the latter, only global average activities will be printed...?
so use MPSTAT or SYSSTAT commands on a SMP computer... lil more info here https://linoxide.com/monitoring-2/10...-command-line/ |
11-06-2019, 08:20 PM | #5 |
Human being with feelings
Join Date: Aug 2011
Location: Near a big lake
Posts: 3,943
|
What specific plugins are you running and how many of each? Are any of them bridged somehow (Windows plugins running in Linux)?
Do you notice PDC for any of them? You can see this in the fx browser window (when the effect is selected) at the bottom where it says "CPU" (right beside that, it says "spls"). Also you can see in the Reaper performance meter how much PDC there is per track. |
11-08-2019, 12:48 AM | #6 |
Human being with feelings
Join Date: Feb 2019
Location: Zürich, Switzerland
Posts: 8
|
These are the Plugin pipelines I've currently got:
It seems I have a thing for TyrellN6, didn't realise that until now. All Linux native, I don't use Wine. About the PDCs, what exactly am I looking for? Looking at the CPU info, I didn't see anything suspicious.
__________________
openSUSE Leap 15.1 i7-6820HQ 2.7GHz (4 Cores, 8 Threads), 32GB RAM |
11-08-2019, 12:54 PM | #7 |
Human being with feelings
Join Date: Mar 2017
Posts: 861
|
I think it might also be lucky to use only vsts and reaper,
no plugins with java, carla, lv2, ladspa etc, and try other effects than zyn, like the Dragonfly and zita reverbs, and vst versions of the mda, drow and zam collections. Search vst in synaptic for more linux vsts, assuming kx-repos are enabled. Citing the old theory, 'too many cooks spoil the broth' If that does not help, at least you'll have seen more options for future use. Cheers |
11-08-2019, 02:06 PM | #8 | |
Human being with feelings
Join Date: Aug 2011
Location: Near a big lake
Posts: 3,943
|
Quote:
Yes I see you like Tyrell No6. And I see what CPU you're using, and its clock speed. You're using too many of those plugins. Realtime CPU is going to get hit hard especially with an open MIDI editor. I just ran one instance of that plugin and got my realtime CPU to 20% with an open MIDI editor. My CPU is a Ryzen 3700X. The fact its "normal" CPU is over 1% on my system (not counting the realtime process) is quite something too; that's one CPU-hungry plugin. Check your realtime CPU use in the Reaper performance meter. You may have to right-click in the meter and enable that. Realtime processes work on a single core or thread, so if you're demanding too much of the realtime aspect of Reaper, that's why this is happening. Also I notice that Tyrell No6 has some PDC. (You can see it where I mentioned it in the last post.) It's not a lot, but any plugin which requires PDC that's running realtime (let's say you're playing it live from a keyboard and monitoring it), let alone with a MIDI editor open, that's going to push your CPU. You can increase your audio device's ALSA or Jack buffer and maybe that'll help somewhat. I recommend using fewer of those plugins at once. You may also find some settings for the MIDI editor that will help in Reaper preferences (under "audio->buffering"). You can also disable hyperthreading to help get the most performance from each core instead of splitting it to threads. That's just what I noticed based on that one plugin, which I was able to download and test quickly. Add more plugins into that mix including any bridges to LV2 (etc.)...it makes sense this is happening on your system. |
|
11-09-2019, 02:44 AM | #9 |
Human being with feelings
Join Date: Feb 2019
Location: Zürich, Switzerland
Posts: 8
|
What is PDC? Or better: How do I read this information? "a%/b% CPU x/y spls" → what are a, b, x and y?
Anyway, that makes sense, thanks. So all RT stuff is done in a single thread, because synths and (audio) effects are RT, they're all in that thread and Reaper is actually using only one core – probably more, but simple MIDI processing and moving a vertical bar in the UI is negligible and probably invisible. It's currently the concept to use synthesizers only and I may even replace the drum samples later, so I'll just have to freeze the tracks. However, I don't see why it's not using multiple cores for freezing, because this isn't RT. Just hypothetically: it would be interesting to reserve one core for Reaper's RT processing and disable just this core's SMT sibling (e.g. on my machine, reserve CPU-0 for Reaper's RT thread and take CPU-4 offline). Finding out how to do that might be interesting for some applications, although I doubt it would make much of a difference.
__________________
openSUSE Leap 15.1 i7-6820HQ 2.7GHz (4 Cores, 8 Threads), 32GB RAM |
11-09-2019, 04:47 AM | #10 |
Human being with feelings
Join Date: Mar 2008
Location: Planet Earth
Posts: 9,098
|
Disabling Hyperthreading might have a positive effect as HT are synthetic cores and can't process real time stuff like a real physical core. REAPER's developer Justin recently posted here how HT is generally a performance hit rather than an improvement for RT tasks.
|
11-09-2019, 11:06 AM | #11 |
Human being with feelings
Join Date: Sep 2018
Location: Colorado
Posts: 429
|
Single core RT processing can easily get overloaded by certain plugins. I also believe that Could there also be overlapping of the 'paths priority' on conflicting plugins - simpler is better type thing. just another thought.
You said you are primarily using MIDI - it might be worth looking into Preferences>Project>Track/Send/Default and see if you can get away with just MIDI as the 'sends send as MIDI' by default instead of MIDI and Audio? just a thought. Could there also be overlapping of the 'paths priority' on conflicting plugins - just another thought. Hey here is a great podcast discussing the history present and future of Reaper development from down under in Melbourne. He is on another forum I am working on - here is his interview with Justin just aired this month... https://dawbench.libsyn.com/episode-...present-future |
11-09-2019, 12:01 PM | #12 |
Human being with feelings
Join Date: Sep 2018
Location: Colorado
Posts: 429
|
What I do sometimes is to render the audio tracks (and attached plugins) as one simple recorded track and disable the track(s) with the plugins. This is simple but helps a lot, Freeing cpu for basically just midi. I can always go back and enable it.
|
11-09-2019, 12:36 PM | #13 |
Human being with feelings
Join Date: Aug 2007
Location: Luxembourg/Spain
Posts: 1,922
|
Do you by any chance leave the synth tracks rec enabled?
This causes them to run realtime (I think), otherwise they ought to be processed in advance (and in parallel) and not have a great impact on the main audio thread? Also many plugins on the master track can have a big impact on the rt cpu measurement.
__________________
Reaper for Linux Documentation (WIP). Software: Archlinux/KDE, Fabfilter FX, Komplete 8, Nebula, Schwa/Stillwell, T-racks Max/Amplitube/SVX, etc. Gear: i7-2600k/4700HQ/16GB, RME Multiface/Babyface, Behringer X32, Genelec 8040, etc. :) |
11-09-2019, 01:20 PM | #14 | |
Human being with feelings
Join Date: Aug 2011
Location: Near a big lake
Posts: 3,943
|
Quote:
A= % of CPU use of the selected plugin. B= % of CPU for all effects on the track combined. X= # of samples latency for the selected plugin. y= # of samples latency total for all effects on the track combined.* % CPU use is based on your current clock speed of the CPU, which can throttle based on your CPU frequency governor setting. For demanding projects it's best to set your CPU frequency governor to "performance", which is the full clock speed. I do this using a small app in the taskbar called indicator-cpufreq. (MS Windows users should do this too, but through the "power settings" app in control panel.) *PDC happens in "chunks" based on the buffer block size of your audio device. Since I set my audio device buffer block size to 64 (using a few blocks at that size), the smallest amount of PDC I can have is 64 samples for instance (even if a plugin seems to just need 3 samples). So if you have one plugin on the track and it shows "3/64 spls", that's what it means. If I set my audio device's buffer to a higher block size such as 128, then the minimum PDC I can get is 128 samples (and that same effect would show "3/128 spls" if it were the only plugin on the track). Processing this PDC realtime contributes to loading the CPU, so if you can choose a plugin that doesn't have latency (PDC) then that would help when running "live" (monitoring the track, such as playing keyboard through the plugin). Have you tried other synth plugins? TAL Noisemaker is a good one and it takes significantly less CPU (normal and realtime). That's a simple .so file download from the Distrho site. There are a number of other synth plugins for Linux which are quite good, so maybe you can substitute some of the Tyrell No6 instances with other synths (saving Tyrell No6 for when you really want its sound specifically). Plus also what Glen, s wave and Jack said, of course. |
|
11-09-2019, 03:08 PM | #15 |
Human being with feelings
Join Date: Jul 2013
Location: Portugal
Posts: 1,827
|
Thanks for all the input james, in a 464 pages manual there is no line saying what the FX percentage mean. your words should be there.
Anyway, for the best performance on your system ( to the author of the post) nothing better then trying different settings. Most has been said on what you could try to do. I normally print the VSTi tracks, like that i keep CPU on low values for the mix without having RT CPU running for the instruments and leaving plenty of space for the mix. i use outboard gear too so FX processing /multiprocessor settings may change to different projects. |
11-09-2019, 03:43 PM | #16 |
Human being with feelings
Join Date: Aug 2011
Location: Near a big lake
Posts: 3,943
|
The effects CPU % readout of the fx browser window made sense to me intuitively especially when also comparing to the Reaper performance meter. The part about that % being based on your CPU's "current ability to perform" (basically its clock speed, and whether it's throttled or not) is something that made sense to me later.
The "spls" aspect didn't seem intuitive to me though; that's something I've read about on the forums, and done some tests with, to realize what it means. It may be mentioned in the user guide but I admit I have never read the guide in its entirety...or even close. |
11-10-2019, 02:58 AM | #17 | |
Human being with feelings
Join Date: Feb 2019
Location: Zürich, Switzerland
Posts: 8
|
Thanks a lot to JamesPeters for the insight.
Quote:
BTW, you can toggle SMT (Hyperthreading) without rebooting on modern kernels: Code:
echo off | sudo tee /sys/devices/system/cpu/smt/control echo on | sudo tee /sys/devices/system/cpu/smt/control # check current status cat /sys/devices/system/cpu/smt/control Code:
# replace "user" with your username user ALL=(root) NOPASSWD:/usr/bin/tee /sys/devices/system/cpu/smt/control Code:
#!/usr/bin/env bash set -e function set-smt() { echo -n "Setting SMT " echo $1 | sudo tee /sys/devices/system/cpu/smt/control } case "$1" in on|off) set-smt $1 ;; status) echo -n "SMT " cat /sys/devices/system/cpu/smt/control ;; toggle) A=on [[ "$(cat /sys/devices/system/cpu/smt/control)" == on ]] && A=off set-smt $A ;; panel-status) echo -n "<txt>" STAT="$(cat /sys/devices/system/cpu/smt/control)" echo -n "SMT $STAT" echo -e "</txt><tool>SMT $STAT</tool><txtclick>\"$0\" toggle</txtclick>" ;; *) echo "USAGE: $0 on|off|status|toggle" exit 1 esac
__________________
openSUSE Leap 15.1 i7-6820HQ 2.7GHz (4 Cores, 8 Threads), 32GB RAM |
|
11-12-2019, 12:05 AM | #18 |
Human being with feelings
Join Date: Sep 2018
Location: Colorado
Posts: 429
|
Thanks Abnaxos... great details too.
|
Thread Tools | |
Display Modes | |
|
|