Better performance in Windows

[sysrqer]

It pains me to say this but I am getting better performance in windows than linux. I am running VCV Rack and I noticed that in linux I am getting more crackles and slowdowns than I would expect with my computer spec so I booted into Windows and loaded the same patch and the playback is much smother.

In windows I can go down to 256 buffers with the mentioned patch whereas in linux I am getting xruns and audible slowdowns at 1024. I've tried a few different kernels (ubuntu low latency, avlinux rt, liquorix) and the low latency seems to be best so far, and I have tried running from a minimal window manager (fluxbox, normally running plasma 5) which helped slightly but not significantly.

Any ideas why this might be happening?

This is the spec:

Code: Select all

System:    Host: hyperion Kernel: 5.4.0-42-lowlatency x86_64 bits: 64 compiler: gcc v: 9.3.0 Desktop: KDE Plasma 5.19.4 
           Distro: KDE neon 20.04 5.19 base: Ubuntu 20.04 LTS Focal 
Machine:   Type: Desktop Mobo: ASUSTeK model: PRIME A320M-K v: Rev X.0x serial: <superuser/root required> 
           UEFI: American Megatrends v: 5409 date: 01/07/2020 
CPU:       Topology: 8-Core model: AMD Ryzen 7 2700 bits: 64 type: MT MCP arch: Zen+ rev: 2 L2 cache: 4096 KiB 
           flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm bogomips: 102195 
           Speed: 2620 MHz min/max: 1550/3200 MHz Core speeds (MHz): 1: 2667 2: 2710 3: 2798 4: 2984 5: 2735 6: 2425 7: 3615 
           8: 3613 9: 2857 10: 2827 11: 2412 12: 2790 13: 3580 14: 3617 15: 2526 16: 2949 
Graphics:  Device-1: Advanced Micro Devices [AMD/ATI] Baffin [Radeon RX 550 640SP / RX 560/560X] vendor: XFX Pine 
           driver: amdgpu v: kernel bus ID: 07:00.0 
           Display: x11 server: X.Org 1.20.8 driver: amdgpu FAILED: ati unloaded: fbdev,modesetting,vesa tty: N/A 
           OpenGL: renderer: Radeon RX 550 Series (POLARIS11 DRM 3.35.0 5.4.0-42-lowlatency LLVM 10.0.0) v: 4.6 Mesa 20.0.8 
           direct render: Yes 
Audio:     Device-1: AMD Baffin HDMI/DP Audio [Radeon RX 550 640SP / RX 560/560X] vendor: XFX Pine driver: snd_hda_intel 
           v: kernel bus ID: 07:00.1 
           Device-2: Advanced Micro Devices [AMD] Family 17h HD Audio vendor: ASUSTeK driver: snd_hda_intel v: kernel 
           bus ID: 09:00.3 
           Device-3: Focusrite-Novation Launchpad MK2 type: USB driver: snd-usb-audio bus ID: 3-3:2 
           Device-4: Focusrite-Novation Focusrite Scarlett 6i6 type: USB driver: snd-usb-audio bus ID: 3-4:3 
           Sound Server: ALSA v: k5.4.0-42-lowlatency 
Network:   Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet vendor: ASUSTeK driver: r8169 v: kernel port: e000 
           bus ID: 05:00.0 
           IF: enp5s0 state: down mac: d4:5d:64:a7:8a:e2 
           Device-2: Realtek RTL8192EE PCIe Wireless Network Adapter driver: rtl8192ee v: kernel port: d000 bus ID: 06:00.0 
           IF: wlp6s0 state: up mac: 50:2b:73:d8:07:13 
Drives:    Local Storage: total: 1.14 TiB used: 823.76 GiB (70.4%) 
           ID-1: /dev/sda model: 256GB PCS 2.5 SSD size: 238.47 GiB temp: 40 C 
           ID-2: /dev/sdb vendor: Seagate model: ST1000DM010-2EP102 size: 931.51 GiB temp: 31 C 
Partition: ID-1: / size: 159.54 GiB used: 63.26 GiB (39.7%) fs: ext4 dev: /dev/sda5 
Sensors:   System Temperatures: cpu: 36.5 C mobo: N/A gpu: amdgpu temp: 40 C 
           Fan Speeds (RPM): N/A gpu: amdgpu fan: 1184 
Info:      Processes: 370 Uptime: 7m Memory: 15.64 GiB used: 2.30 GiB (14.7%) Init: systemd runlevel: 5 Compilers: gcc: 9.3.0 
           Shell: bash v: 5.0.17 inxi: 3.0.38  

This is the output of the realtimeconfigquickscan:

Code: Select all

== GUI-enabled checks ==
Checking if you are root... no - good
Checking filesystem 'noatime' parameter... 5.7.0 kernel - good
(relatime is default since 2.6.30)
Checking CPU Governors... CPU 0: 'performance' CPU 1: 'performance' CPU 10: 'performance' CPU 11: 'performance' CPU 12: 'performance' CPU 13: 'performance' CPU 14: 'performance' CPU 15: 'performance' CPU 2: 'performance' CPU 3: 'performance' CPU 4: 'performance' CPU 5: 'performance' CPU 6: 'performance' CPU 7: 'performance' CPU 8: 'performance' CPU 9: 'performance'  - good
Checking swappiness... 10 - good
Checking for resource-intensive background processes... none found - good
Checking checking sysctl inotify max_user_watches... >= 524288 - good
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... 'threadirqs' kernel parameter - good
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.

I'm starting jack with qjackctl and 48Khz, 1024 buffers, periods 3. Everything else default.

[Doc91b]

If your interface is capable of higher than 48kHz sample rate, set JACK to use the interface's maximum. You can always downsample later. I find that JACK runs far smoother and at much less latency at higher sample rates. That was counterintuitive for me at first, but it worked like a charm when I was first setting up my rig and having latency and xrun problems. Pair your interface's highest sample rate with 256 buffer and 3 period.

If your interface will do 96k: use 96k, 256 buffer, 3 periods.

Same values work with 192k as far as I've tested, but I haven't used that sample rate extensively like I have 96k. I haven't messed with settings under 96k at all, so below that, ymmv.

Hope this helps.

[bhilmers]

If your interface will do 96k: use 96k, 256 buffer, 3 periods.

This recommendation is in line with the explanation of JACK buffers on this page (which cites a post by autostatic on this forum regarding the Focusrite Scarlett 2i4). I haven't used JACK in a while, can anyone confirm this explanation is solid with regards to latency? Does non-integer latency increase xruns?

[sysrqer]

If your interface is capable of higher than 48kHz sample rate, set JACK to use the interface's maximum. You can always downsample later. I find that JACK runs far smoother and at much less latency at higher sample rates. That was counterintuitive for me at first, but it worked like a charm when I was first setting up my rig and having latency and xrun problems. Pair your interface's highest sample rate with 256 buffer and 3 period.

If your interface will do 96k: use 96k, 256 buffer, 3 periods.

Same values work with 192k as far as I've tested, but I haven't used that sample rate extensively like I have 96k. I haven't messed with settings under 96k at all, so below that, ymmv.

Hope this helps.

I just gave this a try and unfortunately it had a negative impact when running a heavy project. The latency was certainly less but it seemed like a lot more CPU was being used. I think this is the crux of the problem, it seems like I am not getting as much usable power out of the CPU as I do in Windows with the same settings.

[merlyn]

I've tried out VCV rack and I can confirm that it won't go down to very low latencies without Xruns. My impression is that this is a VCV rack problem not a Linux problem. The JACK implementation on VCV rack certainly isn't the best. For example it's part of JACK to be able to change the buffer size on the fly. Doing this crashes VCV rack.

I have noticed that I get better performance when the GUI is not visible, so there's something not quite right.

As an example of an app with a good JACK implementation -- Guitarix. On my system Guitarix will run without Xruns with a buffer of 8.

[Kott]

Is VCV able to run without Jack?

[khz]

loaded the same patch

If you can upload the patch here, other users can test it with their LAW and compare it with their Windows computers. At least with Linux there might be different configurations.

Is VCV able to run without Jack?

Yes, VCVRack can also only run with ALSA.
(Test it yourself, VCVRack does not need to be installed. Just unzip it and click on "Rack" in the subfolder).

[sysrqer]

loaded the same patch

If you can upload the patch here, other users can test it with their LAW and compare it with their Windows computers. At least with Linux there might be different configurations.

Is VCV able to run without Jack?

Yes, VCVRack can also only run with ALSA.
(Test it yourself, VCVRack does not need to be installed. Just unzip it and click on "Rack" in the subfolder).

Here is the patch, you will need quite a few different modules installed - https://i.imgur.com/tNAZuNG.png

I've just tried with 44.1khz and there's quite an improvement, I managed to go down to 256 with only occasional glitches. Running with alsa alone didn't really make any difference, it was worse if anything.


Merlyn, did you try changing the Frame Rate under View? It's quite GPU intensive so that can sometimes help.

[merlyn]

Merlyn, did you try changing the Frame Rate under View? It's quite GPU intensive so that can sometimes help.

I did, yes. I fired VCV up again to check what was going on and the frame rate is 10Hz -- the lowest value. It sure is GPU intensive -- I hear the fan in my graphics card spinning up.

Warning: waffle ahead.

So I was trying this out like I would a hardware synth -- by playing it with a MIDI keyboard. The recommendation to learn it is to start with the basic modules that come with it, get to know them, then branch out. OK, so a basic oscillator, no problem. I wouldn't have thought that would put much strain on the CPU but here come the Xruns. WTF? No problem, put the buffer size up. Well actually that is a problem. It crashes, requiring the process to be killed.

The tendency is to think it's something wrong with the system config, as that is so often the case when using Linux. After investigating for a bit I don't think it is the system config -- it's VCV Rack. Using htop the way the processes are divided up and which ones have RT priority looks unusual. It seems to me that because the audio and graphics are so tightly related this app is a bit different from other audio apps. In my model of what's going in the Linux pro audio stack audio should always have priority over graphics. I would want the audio buffer to be filled even if the Third World War kicks off. That's not how this appears to work.

If VCV can work efficiently in Windows I would think it's also possible in Linux, but I get that 50,000 requests for ASIO or whatever will take precedence over optimising the Linux version.

[Kott]

I think this has to be reported on VCV Rack GH page with proper description and ps, htop outputs.

[merlyn]

I had a look on GitHub and the developer is working on version 2. The real bug here is that it is not possible to change the JACK buffer on the fly. On my system using a JACK buffer of 128 results in zero Xruns for simple patches. 128 is right on the limit for me of playability. A lot of people use VCVRack with built-in sequencers and generators, so latency isn't an issue. I should report the JACK buffer bug though.

[mixe]

Is VCV able to run without Jack?

Yes, and I get better performances that way. Alsa only, without even starting Jack.

I can't tell if this is because of wrong system audio settings on my part, relatively old hardware, or VCV issues. I did quite a few attempts at getting good performances with VCV Rack while using Jack and at some point I just stuck with Alsa only. I'm going to wait for VCV 2.x before I'll do other attempts.

On the other hand, I've been following the development of VCV Rack and I believe there's no reason to expect Linux support is -or is going to be- suboptimal compared to Windows. I'm more prone to blame the general state of audio in Linux.

[sysrqer]

Is VCV able to run without Jack?

Yes, and I get better performances that way. Alsa only, without even starting Jack.

Did you do anything to configure alsa? I think most of the time I don't really need Jack but I just tried alsa again and I definitely get worse performance from it even with higher buffer sizes.

[Xzu Rukneg]

qjackctl and 48Khz, 1024 buffers, periods 3

In qjackct, did you check:
-realtime :activated
-rt priority: 70

More khz => less latency

less buffer and periode => less latency