Bad performance without compositing - Linux

Help, Support & Bugs
1

Hi,

today I found some strange behaviour for which I don’t have any explanation. I’m using RENOISE on Debian / Stretch with the XFCE desktop. I’m using the debian stock kernel (4.9.0-8-amd64) at the moment. But I observe the same behaviour also with the Real Time kernel.

When I disable the compositing in XFCE or don’t use Compton (using both at the same time is not possible) as the compositor I very quickly get xruns and the DSP load is driving roller coaster. Renoise is becoming very slow and the xorg process reaches almost 100%.

When I enable Compton or the XFCE own compositor everything goes back to normal. Strange thing is that I never stumbled upon that issue. Also I would think that using a compositor will make xruns more likely in any case, but actually this is not what I observe.

I made a little video:
While it’s playing with Compton until ~ 0:30 the Renoise DSP load is ~16%.
Then after killing compton it’s increasing to 25% and running a xrun counter script gives the first xruns at ~64% or lower…and Renoise is becoming slow.

At 1:55 I started compton again and DSP load goes down again. When starting the xrun counter script I get the first xrun at ~ 90% (not shown).

When the Renoise window is closed CPU usage goes down. I did also the same test with REAPER and I don’t see any difference there between activated or deactivated compositing. Is there any explanation for this?

some more info about my graphics:

[code]/etc/modprobe.d$ inxi -G
Graphics: Card: Intel Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller
Display Server: X.Org 1.19.2 drivers: modesetting (unloaded: fbdev,vesa)
Resolution: 1920x1080@60.00hz
GLX Renderer: Mesa DRI Intel Haswell Desktop GLX Version: 3.0 Mesa 13.0.6

lxinfo | grep -i vendor
server glx vendor string: SGI
client glx vendor string: Mesa Project and SGI
Vendor: Intel Open Source Technology Center (0x8086)
OpenGL vendor string: Intel Open Source Technology Center

00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller [8086:0412] (rev 06) (prog-if 00 [VGA controller])
Subsystem: Micro-Star International Co., Ltd. [MSI] Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller [1462:7817]
Flags: bus master, fast devsel, latency 0, IRQ 32
Memory at f7800000 (64-bit, non-prefetchable) [size=4M]
Memory at e0000000 (64-bit, prefetchable) [size=256M]
I/O ports at f000 [size=64]
[virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
Capabilities:
Kernel driver in use: i915
Kernel modules: i915

lsmod

Module Size Used by
snd_seq_dummy 16384 0
snd_hrtimer 16384 1
binfmt_misc 20480 1
hid_generic 16384 0
usbhid 53248 0
hid 122880 2 hid_generic,usbhid
cpufreq_userspace 16384 0
cpufreq_powersave 16384 0
cpufreq_conservative 16384 0
snd_hda_codec_hdmi 49152 1
intel_rapl 20480 0
x86_pkg_temp_thermal 16384 0
intel_powerclamp 16384 0
kvm_intel 200704 0
kvm 598016 1 kvm_intel
iTCO_wdt 16384 0
iTCO_vendor_support 16384 1 iTCO_wdt
irqbypass 16384 1 kvm
crct10dif_pclmul 16384 0
mxm_wmi 16384 0
crc32_pclmul 16384 0
evdev 24576 8
ghash_clmulni_intel 16384 0
snd_hda_codec_realtek 90112 1
intel_cstate 16384 0
intel_uncore 118784 0
snd_hda_codec_generic 69632 1 snd_hda_codec_realtek
i915 1257472 23
intel_rapl_perf 16384 0
snd_hda_intel 36864 0
drm_kms_helper 155648 1 i915
snd_usb_audio 180224 4
serio_raw 16384 0
snd_hda_codec 135168 4 snd_hda_intel,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_codec_realtek
drm 360448 6 i915,drm_kms_helper
snd_usbmidi_lib 28672 1 snd_usb_audio
mei_me 36864 0
snd_hda_core 90112 5 snd_hda_intel,snd_hda_codec,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_codec_realtek
lpc_ich 24576 0
sg 32768 0
i2c_algo_bit 16384 1 i915
mei 102400 1 mei_me
snd_hwdep 16384 2 snd_hda_codec,snd_usb_audio
mfd_core 16384 1 lpc_ich
shpchp 36864 0
wmi 16384 1 mxm_wmi
video 40960 1 i915
button 16384 1 i915
snd_seq_midi 16384 1
snd_seq_midi_event 16384 1 snd_seq_midi
snd_seq 65536 8 snd_seq_midi_event,snd_seq_dummy,snd_seq_midi
snd_rawmidi 32768 2 snd_seq_midi,snd_usbmidi_lib
snd_seq_device 16384 3 snd_seq,snd_rawmidi,snd_seq_midi
snd_aloop 24576 2
snd_pcm 110592 9 snd_hda_intel,snd_hda_codec,snd_usb_audio,snd_hda_core,snd_hda_codec_hdmi,snd_aloop
snd_timer 32768 4 snd_seq,snd_hrtimer,snd_pcm
snd 86016 22 snd_hda_intel,snd_hwdep,snd_seq,snd_hda_codec,snd_usb_audio,snd_timer,snd_rawmidi,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_usbmidi_lib,snd_seq_device,snd_aloop,snd_hda_codec_realtek,snd_pcm
soundcore 16384 1 snd
nct6775 57344 0
hwmon_vid 16384 1 nct6775
coretemp 16384 0
parport_pc 28672 0
ppdev 20480 0
lp 20480 0
parport 49152 3 lp,parport_pc,ppdev
ip_tables 24576 0
x_tables 36864 1 ip_tables
autofs4 40960 2
ext4 585728 3
crc16 16384 1 ext4
jbd2 106496 1 ext4
crc32c_generic 16384 0
fscrypto 28672 1 ext4
ecb 16384 0
mbcache 16384 4 ext4
sr_mod 24576 0
cdrom 61440 1 sr_mod
sd_mod 49152 6
uas 24576 1
usb_storage 73728 1 uas
crc32c_intel 24576 6
aesni_intel 167936 1
ahci 40960 3
libahci 32768 1 ahci
aes_x86_64 20480 1 aesni_intel
glue_helper 16384 1 aesni_intel
lrw 16384 1 aesni_intel
gf128mul 16384 1 lrw
ablk_helper 16384 1 aesni_intel
cryptd 24576 3 ablk_helper,ghash_clmulni_intel,aesni_intel
libata 249856 2 ahci,libahci
xhci_pci 16384 0
ehci_pci 16384 0
i2c_i801 24576 0
xhci_hcd 188416 1 xhci_pci
i2c_smbus 16384 1 i2c_i801
ehci_hcd 81920 1 ehci_pci
psmouse 135168 0
scsi_mod 225280 6 sd_mod,usb_storage,libata,uas,sr_mod,sg
r8169 86016 0
mii 16384 1 r8169
usbcore 253952 9 usbhid,snd_usb_audio,usb_storage,ehci_hcd,xhci_pci,snd_usbmidi_lib,uas,xhci_hcd,ehci_pci
usb_common 16384 1 usbcore
fan 16384 0
thermal 20480 0

[/code]

~/rns_3_1_1_linux_x86_64$ ldd renoise
linux-vdso.so.1 (0x00007ffc6c020000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f020f676000)
libasound.so.2 => /usr/lib/x86_64-linux-gnu/libasound.so.2 (0x00007f020f369000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f020f14c000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f020ef48000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f020ed40000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f020e9be000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f020e6ba000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f020e4a3000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f020e104000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f020dedc000)
/lib64/ld-linux-x86-64.so.2 (0x00007f020f9b6000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f020dcd8000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f020dad2000)
libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f020d8bc000)

2

Have you already done this?

Just launch to check what you need to do:

perl ./realTimeConfigQuickScan.pl

Though clearly it’s something weird going on, at least doing what’s listed in those scripts should eliminate a lot of usual suspects for performance problems :slight_smile:

1 Like
3

Hi, thanks!

Yup, I optimized everything and can post the output later. I also will make a test if Redux shows the same. Maybe taktik or any dev has a clue what’s happening here.

When I close the renoise window it’s fine, so I suspect that the Renoise GUI is consuming too much CPU.

4

This couldn’t be a cpu cooler issue by chance? I had a fair share of these lately, so i thought i should throw it out as it can be easy to overlook.

5

I don’t think so as it correlates with the compositor. The Fan speeds are as always, but I double check later.

6

Maybe deactivating the compositor somehow disables graphics hardware acceleration at one stage or another. Then it could be possible that the renoise gui or the wm suddenly use a lot of cpu power for tasks that were using the gpu before. This cpu power might then be missing for audio tasks.

2 Likes
7

That’s good point, @lilith have you tried to launch renoise from terminal with compositor already killed before?

8

Thanks for helping! I did some more tests.

When booting the PC and opening a blank Renoise project without compositor, Renoise already uses ~12% CPU (Renoise CPU meter) and total CPU usage is 25% (Taskmanager), respectively. When activating compositor it drops to ~2% and 11%, respectively. When closing the Renoise window without compositor I get ~3% Taskmanager CPU usage. The same I get with activated compositor. The Renoise CPU load largely resembles the DSP load of Jack. So, why does the GUI need so much DSP (which should be reserved for audio processing?). I think it’s more a DSP than a CPU problem, the CPU usage is moderate mostly (except that xorg takes a lot of CPU when I leave Renoise running longer with deactivated compositor).

Another observation: When transport is running in a blank project the Renoise CPU load is higher (up to 15%) compared to when transport is stopped (8%). Same is true when the spectrometer windos is shown → CPU load is increasing. With activated compositor there’s hardly any difference.

What zer0 Fly wrote seems to be right, but on the Renoise site it’s written:

Checking the graphical environment

If you are using Linux in a graphical environment you should have X.org installed and working (X.org runs under desktop environment like GNOME, KDE or XFCE… so if you are using any of those you also have X.org installed).Please avoid compositing windowmanagers like Compiz or Beryl (or the Fusion combination) as they consume a load of CPU resources and specially the older versions supply problems when Renoise runs “Fullscreen”. Also see:Troubleshooting → Performance problems.

So, I assume it should be fine with any compositor too.

When I load Redux into Reaper I also don 't see any significant difference between activated / deactivated compositor.

Here’s another video where it gets more clear:

Here’s the script output:

== GUI-enabled checks ==
Checking if you are root… no - good
Checking filesystem ‘noatime’ parameter… 4.9.0 kernel - good
(relatime is default since 2.6.30)
Checking CPU Governors… CPU 0: ‘performance’ CPU 1: ‘performance’ CPU 2: ‘performance’ CPU 3: ‘performance’ - good
Checking swappiness… 10 - good
Checking for resource-intensive background processes… none found - good
Checking checking sysctl inotify max_user_watches… < 524288 - not good
increase max_user_watches by adding ‘fs.inotify.max_user_watches = 524288’ to /etc/sysctl.conf and rebooting
For more information, see System configuration [Linux-Sound]
Checking access to the high precision event timer… readable - good
Checking access to the real-time clock… readable - good
Checking whether you’re in the ‘audio’ group… yes - good
Checking for multiple ‘audio’ groups… no - good
Checking the ability to prioritize processes with chrt… yes - good
Checking kernel support for high resolution timers… found - good
Kernel with Real-Time Preemption… not found - not good
Kernel without real-time capabilities found
For more information, see System configuration [Linux-Sound]
Checking if kernel system timer is high-resolution… found - good
Checking kernel support for tickless timer… found - good
== Other checks ==
Checking filesystem types… ok.
** Set $SOUND_CARD_IRQ to the IRQ of your soundcard to enable more checks.
Find your sound card’s IRQ by looking at ‘/proc/interrupts’ and lspci.

9

So, I assume it should be fine with any compositor too.

Well, reality could be a little worse, though i can’t say that Compton is heavy…Should be fine

Don’t forget this, could help)

I’ve noticed you’re testing specific project, which have VSTs like Diva and Repro (they’re pretty heavy on resources) and since it’s Linux you most likely use some kind of bridge for Wine, like airwave?

That could be problem, since airwave and wine aren’t most stable things on planet yet)(

btw i personally plan to invest a lot of time in testing / helping airwave dev soon, so if this is the case hopefully in the future it will be better.

So, just for test try some project without VSTs, like one of Renoise demo songs

Other than that i’m out of ideas, hopefully @taktik should know better :slight_smile:

10

Are you sure all cores of your CPU are used? Oh and what happens if you remove Repro-1?

11

The issue is not related to any VSTs, as I already see a huge difference in a blank, completely empty project. There Renoise uses already 12%, just for the GUI. All 4 CPU seems to be used. When I choose 1 CPU in Renoise the CPU usage increases from 30 to over 50%. With activated compositor it still plays fine with even 1 CPU without xruns.

When I remove Repro-1 nothing really happens. I also don’t have any bridge or wine running. Only native Linux plugins.

1 Like
12

Maybe then the stepping of your cpu doesn’t work and it runs at too low clock? Since Renoise GUI is drawn a lot by CPU, it uses some CPU. The analysers take quite a lot. On my 4 core 4k systen Renoise GUI with analyzer uses like 74% of one core (since pixel amount is quadrupled). So it is pretty normal Renoise GUI eats lot of CPU, but maybe not that much. Also you only have full hd.

13

CPU runs at 3.3 Ghz on performance mode.

lscpu | grep MHz
CPU MHz: 3320.703

14

No idea then, also do not getting the problem :smile: Then enable Compton?

15

Holy crap! Are you for real?

I use Manjaro Deepin with x2 cores 2,5gHz core2duo / 4 Gb RAM and it uses 0 CPU on idle…
Well, at least with default deepin-mutter compositor

I’d say you both have something wrong going on :alien:

16

With Reaper or Ardour everything is fine … seems to be a Renoise GUI issue …
I could use compton all the time, but as my system very rarely freezes (every 3 months or so) I wanted to make a test without a compositor as it could be responsible for the freezes.

17

What is also funny: When I cover the Renoise analyzer region with any other window (explorer or whatever) the CPU usage decreases. :grimacing:

18

I am on macOS with a 4k resolution. The GUI looks like drawn completely by CPU here. If I switch to fullhd or make the Renoise windows very small, I only have like a quarter of the usage. So I assume that’s a proof that the GUI is drawn by CPU?

19

That sounds like a decent, modern windows manager to me. macOS also has such a feature, covered areas won’t be rendered anymore, but only if the software supports it. Actually seems to me that the Renoise GUI code is much better optimized for Linux than it is for macOS, and uses some hardware acceleration over there? I have no idea, only Taktik could enlighten us.

1 Like
20

Yeah…It seems so, but probably it shouldn’t?

Since i don’t have it for example not on Linux, not on Windows…

What video-drivers do you guys use?