Using the realtime option on linux leads to system lock

VCV Rack
1

Before posting a bug report I’m just wondering if anyone else has had trouble with the realtime option being enabled? For me this option causes the system to lock up and requires a hard power off to recover, although the patch continues to play. Previously this has lead to data loss for the patch I was working on before the crash, on reboot the patch wouldn’t load and was 0kb size.

As far as I’m aware my install is set up for realtime use (I’m in audio group, limits file edited etc) but are there any particular steps or system adjustments I need to do for this setting to not crash my computer? I have done the setcap command on the Squinky Labs wiki.

I see there is a ‘realtime’ group mentioned on the Jack website, is that necessary?

1 Like
2

perhaps is the RT or low latency kernel, do yo have it?

I m not specialist but the RT and low latency kernel allow to you computer serve the priority task before and , it can jump between task easily.

the processor in “performance mode” can help too

take a look of this guide , perhaps can help you https://coroto.gitbook.io/linux-audio-survival-kit/

3

btw, some users report the skjack make a huge difference about the performance
(I cant appreciate that difference)

4

I have done all the steps in that guide. The CPU governor doesn’t seem to make any difference with this problem, it certainly makes patches play better with performance but I’ve had this crash with powersave and performance. I am currently using the lowlatency kernel from ubuntu but I was originally using the liqourix kernel, also a lowlatency kernel. I did a whole distro reinstall because I thought there might be some rogue setting causing a problem so my system is pretty vanilla at the moment other than the system settings mentioned in that article.

There are two things that I think may be involved:

  1. the option requires an actual RT kernel rather than lowlatency
    or
  2. the realtime option conflicts with nvidia

I read that (without a particular patch) you can’t run the full RT kernel with nvidia so I am wondering if this realtime option hitting that conflict somehow. Another thing that draws me to this option is that when I first got my computer I was using the Nouveau driver and I would get system locks with ardour in the exact same way, gui completely frozen but track still playing fine. One of the ardour devs mentioned on the irc that Nouveau is not suitable for realtime operations and I discovered this on the arch wiki (the fix was not there at the time). So it is weird that now I am using nvidia I’m getting the same problem.

It seems to be related to large patches/heavy cpu use, like the audio has more priority than the graphics and they just stop working while the audio keeps going.

I haven’t experienced this with other programs though, I can run renoise, ardour, and reaper without any issue.

5

I have installed in two computers with very different components (intel, ryzen,nvidia, radeon) and both work with real time option nicely (running beside renoise and sometimes carla)

Nouveau is a audio interface? can you run jack in the integrated audio card? how it work ?

I think is not a issue related with the RT or the rack…

6

I never got this issue (yet). My patches may be relatively simple. Can you please send me one of the large patches that trigger this issue? (free modules from the Plugin Manager only please)

My setup:

  • 4.15.0-54-lowlatency kernel
  • “nvidia” driver
  • “Real time priority” in Rack always enabled
  • user is in “audio” group; I have no “realtime” group at all
  • /etc/security/limits.d/audio.conf set as in the mentioned guide
  • QJackCtl shows the “realtime” option as enabled
  • I’m not sure about the governors thing. I can’t remember if I set it up at all. I get the following discouraging output (I haven’t followed up to it yet because I get good performances with Rack 1.x anyway):
    # cpupower frequency-info --governors
    analyzing CPU 0:
    available cpufreq governors: Not Available

I just realized I had forgot to reapply the setcap command to the latest 1.x binaries. I’ll do that and report back.

Let me know if you need other info about my setup.

7

If you don’t already know, this command:

uname -a

reports information about the kernel you’re running, including its RT and PREEMPT status.

Also, what is your framerate value in Rack’s settings.json ? (I’ve set it to 25 here.)

Best,

dp

8

@David nouveau is the open source driver for nvidia cards. I have been using nvidia driver (instead of nouveau for ages but the problem is the same as the one I had with that driver).

@mixer that all looks much the same as me. Here is a patch but I think I can reproduce it with any really. This was the last one I had it happen with, almost as soon as I turn on the option everything halts.

@dlphillips I am running 5.0.0-20-lowlatency. I have it at 70 at the moment, which I guess is the default. I had been running it at 30 I think but I don’t think it made any different to this crash although I will try again when I can reboot.

9

i have also discovered hangs on linux on my sonaremin setup, i.e. running vcvrack on arm cpu systems. at the beginning i was not really sure about the source, but so far it more and more points towards the realtime option as well. i can enable the realtime option fine and it works well, but if the sonaremin starts it starts vcvrack automatically and then often it locks up if the realtime option is enabled. i guess some strange deadlocking is happening here somewhere. the patches i use on the sonaremin are not that big, but as the hardware is less powerful than usual intel systems, there is a high load here as well. it might be interesting to check if the problem appears as well with only one thread running?

best wishes - hexdump

10

That’s interesting to hear, I’m glad that it isn’t only me at least. I don’t remember if the threads made any difference but it could be related. Have you managed to get any logs? I don’t get anything that I can see, I suppose because Rack doesn’t actually crash as such.

I’ve created an issue if you feel commenting there as well.

11

I don’t have Parametra, could you please share a version without it? Even if the patch is currently incomplete, the load oscillates between 4 and 6, and the system looks clearly stressed. Probably heavier than any of my patches.

12

Sorry about that, I forgot that was in there. Here’s another version.

13

hello, maybe you can helpme with this, i’m trying to optimize my new system and there is no framerate in my .json file. is a “frameSwapInterval”: 1, is this the same? thanks

14

You now adjust it via the View menu

image
image773×571 39 KB

15

The problem must be still there because there’s an open, recent bug report about this:

Please comment there (and/or vote by adding :+1:) if it’s affecting you.

It’s also happened recently to me while I was trying to re-configure audio on my Linux box (Kubuntu / Nvidia / 5.4.0-54-lowlatency #60-Ubuntu SMP PREEMPT kernel), I haven’t reported it yet because this computer also has other problems going on.

1 Like
16

I’m sure I read Andrew mentioning that something in V2 would change this or make the option obsolete.

17

Oh, you’re right. Maybe we should just close this thread.

18

Here is it. On a second thought I’m not closing the thread, because we have no idea of when Rack v2 will be available, but when it will:

the “Real-time priority” menu item is removed, since the thread priority is now managed elsewhere (RtAudio, etc.)

source: Rack development blog - #45 by Vortico

1 Like
19

Yeah should keep it open. I think this should have been removed from the Linux builds and released as a point update, considering it is a very critical bug that has caused full system crash and data loss. Until V2 is out this is very much a relevant thread.

1 Like