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?
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:
the option requires an actual RT kernel rather than lowlatency
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.
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.
@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.
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?
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.
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.
The problem must be still there because there’s an open, recent bug report about this:
Please comment there (and/or vote by adding ) 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.
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.