Enabling multicore has opposite effect in Repro5 and Diva

[Robinrobo]

I asked this over in the regular U-he page but determined I may have a linux specific issue so I thought I'd ask again over here.

When I enable multicore mode in Diva, as intended, rt CPU usage goes down and latency time improves according to the performance meter in Reaper. Enabling multicore mode in Repro5 causes rt CPU usage to go up, latency time to go up, and Xruns to increase drastically. I'm using the latest Linux versions of Repro 9669 and Diva 9775, though the same thing happened with previous versions. Also notable I'm using reaper 6.13, a Sandy bridge i5, and a fully up to date avlinux64 so there shouldn't be any issues with rt privileges, memlocks etc.

Is this a known issue? Is it normal? Any fixes?

[lem18]

Semi-related, but thanks for pointing multicore out: I was trying Diva 9775 in Carla and with 5 notes held down with Bryan Lake's ATMOS Frozen Tears patch, DSP usage would go to 99%, output would stop and there was constant Xruns. Enabling multicore fixed all of that (I didn't realise it wasn't enabled by default, or maybe I accidentally turned it off?). This was on a Ryzen 3900X, so no shortage of CPU power.

(Ubuntu Studio 18.04 + KXStudio, Linux 5.8.3 from Ubuntu mainline ppa, Unity desktop, Mesa 20.3-git, RX Vega 56 on RadeonSI)

[Robinrobo]

Semi-related, but thanks for pointing multicore out: I was trying Diva 9775 in Carla and with 5 notes held down with Bryan Lake's ATMOS Frozen Tears patch, DSP usage would go to 99%, output would stop and there was constant Xruns. Enabling multicore fixed all of that (I didn't realise it wasn't enabled by default, or maybe I accidentally turned it off?). This was on a Ryzen 3900X, so no shortage of CPU power.

(Ubuntu Studio 18.04 + KXStudio, Linux 5.8.3 from Ubuntu mainline ppa, Unity desktop, Mesa 20.3-git, RX Vega 56 on RadeonSI)

It's a wonderful thing. They vastly improved it with Diva 1.4 as well.

If I can ask a favour of you would you mind trying the same thing with Repro5, it can be the demo version, and see if Xruns increase or decrease on a big 8 voice patch with lots of modulation? I'm trying to narrow down if it's my problem, and therefore something I can solve, or a bug with the plugins themselves.

I know that the person who maintains the Linux versions is unavailable these days but no one else seems able to assist me in troubleshooting.

[lem18]

If I can ask a favour of you would you mind trying the same thing with Repro5, it can be the demo version, and see if Xruns increase or decrease on a big 8 voice patch with lots of modulation? I'm trying to narrow down if it's my problem, and therefore something I can solve, or a bug with the plugins themselves.

I tried with Repro5 9669, JH Strings Espressivo and managed to get Xruns and DSP load ~70% with 8 notes held down with HQ mode enabled. Multicore mode fixed that., DSP load down to ~33%. JH Vox Chorale was even heavier on the CPU and got Xruns more often.

If you've got a specific patch you want me to test, I can do that.

[Robinrobo]

If I can ask a favour of you would you mind trying the same thing with Repro5, it can be the demo version, and see if Xruns increase or decrease on a big 8 voice patch with lots of modulation? I'm trying to narrow down if it's my problem, and therefore something I can solve, or a bug with the plugins themselves.

I tried with Repro5 9669, JH Strings Espressivo and managed to get Xruns and DSP load ~70% with 8 notes held down with HQ mode enabled. Multicore mode fixed that., DSP load down to ~33%. JH Vox Chorale was even heavier on the CPU and got Xruns more often.

If you've got a specific patch you want me to test, I can do that.

No that's great, very helpful. I really appreciate you doing that for me!

This tells me it's either a problem with my system or it's configuration, a problem with the way reaper handles that plugin and multicore, a problem with the way reaper handles my rather old processor, or a problem with the way repro handles my rather old processor. What's odd to me is that diva and bazille are drastically improved with multicore enabled and repro is worse on my system. Oh well.

Thanks again for the help!

[lem18]

You're welcome. Have you tried hosting them in Carla (what I was testing with), Qtractor, Ardour..? That would narrow it down to whether it's Reaper specifically, or something else on your system.

[Robinrobo]

You're welcome. Have you tried hosting them in Carla (what I was testing with), Qtractor, Ardour..? That would narrow it down to whether it's Reaper specifically, or something else on your system.

Good idea, I will try ardour tomorrow!

[Robinrobo]

You're welcome. Have you tried hosting them in Carla (what I was testing with), Qtractor, Ardour..? That would narrow it down to whether it's Reaper specifically, or something else on your system.

Good idea, I will try ardour tomorrow!

No improvement with Cara unfortunately. I thought it was better at first but it still behaves noticeably worse with mcore mode on. Although I got no Xruns with it off as soon as I turned it on it xran like crazy. I'm using jack+alsa as the engine for the record.

I looked closer at what was happening in Reaper. When enabling mcore mode CPU goes down, rt CPU goes down, but rt longest-block goes up significantly higher than my buffer size and Xruns like crazy. I'm using 44100, 64 samples, and 3 periods and hq mode off. Specifically with mcore on Rt longest-block shows around 9.5/1.45 with 10 keys mashed down in the cs something preset while working the mod wheel. With mcore off it's over 1.3/1.45 occasionally spiking over the limit. CPU with mcore is about 30% and without mcore it's 70% which would imply better performance but the Xruns say different. I tried using reaper's internal multithreaded option instead but that was worse.

Diva on the other hand set to 44100, 64 samples and 3 periods and mashing down 10 keys uses 70% rt CPU and 1.7/1.45 rt longest-blocks without mcore. With mcore enabled it uses 30% rt CPU and 0.7/1.45 rt longest-block so significantly better and more within the intended results.

Something's up here for sure.

Edited to correct an error about Carla behaviour and add more information.

[tasmaniandevil]

Have you tried experimenting with Repro-5's Multicore Threads setting in its preferences?
You can set how many threads Repro should use (from 2 to 8 ).

[Robinrobo]

Have you tried experimenting with Repro-5's Multicore Threads setting in its preferences?
You can set how many threads Repro should use (from 2 to 8 ).

I've tried 4, as many as my processor handles, I'll try some other numbers tonight. Thanks for the suggestion!

[lem18]

Have you observed what frequency your CPU is running at with multicore mode on? Maybe multicore lets it run at a much lower clockspeed and that is causing an issue? I run this in a terminal for an overview:

Code: Select all

watch -n1 "grep Hz /proc/cpuinfo | sort -r"

Which on the Ryzen 3900X at an idle desktop looks like:

Code: Select all

Every 1.0s: grep Hz /proc/cpuinfo | sort -r             zenchi: Tue Aug 25 08:41:43 2020

cpu MHz         : 3132.840
cpu MHz         : 2537.273
cpu MHz         : 2370.491
cpu MHz         : 2225.882
cpu MHz         : 2207.981
cpu MHz         : 2207.974
cpu MHz         : 2198.624
cpu MHz         : 2195.862
cpu MHz         : 2195.813
cpu MHz         : 2195.599
cpu MHz         : 2195.583
cpu MHz         : 2195.577
cpu MHz         : 2195.490
cpu MHz         : 2195.394
cpu MHz         : 2195.358
cpu MHz         : 2195.340
cpu MHz         : 2194.480
cpu MHz         : 2190.837
cpu MHz         : 2189.147
cpu MHz         : 2188.694
cpu MHz         : 2188.646
cpu MHz         : 2174.626
cpu MHz         : 2155.828
cpu MHz         : 2152.225

[Robinrobo]

I tried reducing the number of threads from 4 to 3 and it was a bit better with lower CPU than without more and lower longest-blocks than 4 threads but still not useable. I reduced it to 2 and it was a bit better again, CPU was even lower but longest blocks was still a tiny bit higher than without mcore, unlike diva. This is workable for one instance but doesn't really help for multiple instances. I suspect that this may be the compromise that I need to go with though as it doesn't seem like anyone else has my problem.

The CPU clockspeed wasn't noticeably different with 1, 2, 3, or 4 threads. If it's relevant I have the CPU governer set to performance so that behavior makes sense to me.

[lem18]

Have you checked the CPU usage with htop, or top when you get Xruns? If it's near 100% then that would suggest it's not fast enough. The Sandy Bridge i5s look like they all run around 2.8GHz on 4 cores (no Hyperthreading), I'm not sure if that would be fast enough for all of what you're doing? Especially with your settings.. I don't understand the intricacies of JACK and frames and periods, but I use 44100, 128 frames/period, and 2 periods/buffer for 5.8msec latency. I put your settings in and that's 4.35msec latency. Have you tried increasing the latency a bit to see what effect that has?

In multicore mode, Diva uses 16 threads on my system, and runs fine even with my CPU governor set to powersave (2.1GHz across 24 threads). Repro5 uses however many threads I enabled, and runs fine in powersave up to 8 threads. In single threaded mode, I got Xruns with both when in powersave mode. Schedutil worked fine, but ondemand didn't.. it would cause Xruns in Diva with the ATMOS Frozen Tears patch.

[Robinrobo]

Have you checked the CPU usage with htop, or top when you get Xruns? If it's near 100% then that would suggest it's not fast enough. The Sandy Bridge i5s look like they all run around 2.8GHz on 4 cores (no Hyperthreading), I'm not sure if that would be fast enough for all of what you're doing? Especially with your settings.. I don't understand the intricacies of JACK and frames and periods, but I use 44100, 128 frames/period, and 2 periods/buffer for 5.8msec latency. I put your settings in and that's 4.35msec latency. Have you tried increasing the latency a bit to see what effect that has?

In multicore mode, Diva uses 16 threads on my system, and runs fine even with my CPU governor set to powersave (2.1GHz across 24 threads). Repro5 uses however many threads I enabled, and runs fine in powersave up to 8 threads. In single threaded mode, I got Xruns with both when in powersave mode. Schedutil worked fine, but ondemand didn't.. it would cause Xruns in Diva with the ATMOS Frozen Tears patch.

Great suggestions!

I'm using the Sandy bridge i5 2500k. It is 3.3 GHz pre boost on 4 cores. When it's glitching htop shows it demanding about 35% with multicore enabled on the most taxed core with my really low latency setting and lots of ram to spare which is in line with what the reaper performance meter is showing. At that setting the longest-blocks is what's killing it.

I agree, it is an ambitious setting but it works well for all my other plugins including other demanding U-he ones like bazille with hq enabled and Diva on divine mode and is improved by the mcore switch in all but repro where it is instead negatively effected.

I have tried with 128 frames and it is better but still shows the same issue of the mcore switch increasing the longest blocks while decreasing the CPU which kind of defeats the purpose of the mcore switch. Again it's only repro that that happens with. All the others use half the rt-CPU and half of the Rt longest-block with mcore enabled.

I can totally live with it but if the mcore switch functioned as intended for me it would allow me to use more instances.

[lem18]

Hmmm it is curious! Have you tried backing up your existing Repro folders (in ~/.u-he/), deleting them (or moving them somewhere out of the plugin search path), installing Repro fresh, then trying it? Maybe it's a setting that's gone wrong somewhere in a config file? I'm not sure what else to try with the knowledge I have, but I'd try that just in case. It's interesting that the CPU can handle other heavy U-he plugins but Repro is behaving seemingly opposite with the multicore switch..