Description: I have a pretty big project. With Renoise 3.4.2 it runs nearly rock solid (maybe a couple of xruns over several minutes). With 3.5.3, loading the same project and making no other changes, results in hundreds of xruns per minute.
Unfortunately it’s quite hard to give reproducible instructions, since this is a performance issue. I guess at the moment I’m mainly gauging to see if anyone else has seen this, or if it’s just me.
Play the track while doing rapid focus changes between Renoise and another application. The easiest way to achieve this is to set your window manager to “focus follows mouse”, if it allows that, and quickly move between two windows. But rapidly Alt-tabbing also works.
Experiment and set the Jack period size as low as it can go while still playing the track with no, or very few, xruns, while doing the focus switching.
Now repeat the same procedure with Renoise 3.5.3.
Expected behavior: Renoise 3.4 behavior: The track runs solid, with no, or very infrequent, xruns.
Actual behavior: Renoise 3.5 behavior: The result is much worse, with xruns tens of times, if not hundreds of times more frequent.
Obviously, the rapid focus switching is not something I usually do, it’s just a way that I found to reproduce the problem somewhat consistently. The xruns happen in many other contexts too, so I can’t “work around” the problem by not switching focus.
See also tkna’s reply, they reproduced it in a different way.
Hmm, which setting do you mean exactly? The Jack buffer size? This is set from outside of Renoise, and is the same in both cases. PDC is also disabled in both cases.
Not sure how it works in Linux, but in Windows you can set buffer size for your audio card in the audio settings in the preferences. Can’t you set anything there?
No, when using Jack in Linux, apart from selecting the driver and the number of channels, that section is empty. Buffer size and latency are set by Jack before Renoise is even started.
I did write Jack in the title, but I probably should have been clearer that this is Linux and Jack we’re talking about. I’ll edit the original post to reflect this.
Ok, this is worse than I first thought. Even a single track with a single built-in wav instrument triggers this performance issue easily. I have updated the first post to include reproducible instructions.
Version upgrades may sometimes increase resource consumption.
I don’t think that necessarily constitutes a bug.
Achieving both sufficient buffer size and latency requires appropriate configuration.
Fundamentally, adjusting to use sufficient buffer size at the expense of latency should eliminate xrun.
Additionally, setting the CPU governor to performance mode may improve the situation.
I’m using pipewire-jack without any issues.
If problems persist exclusively with JACK2 no matter how you configure it, Renoise may need to be fixed.
I don’t think resource consumption is the issue here. This started with a huge project with more than forty tracks and loads of plugins. Reducing this to a single track made no difference, the number of xruns is still roughly the same. And the CPU load is very light when I’m running this, so it’s not running out of cycles.
I can confirm that I’m using the performance CPU governor in both cases.
@tkna: Out of curiosity, which period size are you running with? I’m at 256 currently, which is not that low, and I’ve been running Renoise 3.4 at 128 many times, although it is a bit too low for the heaviest projects.
For some additional context, the issue feels very similar to how xruns happen when realtime priority has not been configured correctly. Except I know for a fact that it is configured correctly, because I can see the high priority threads being created in Renoise using top.
When I set the CPU governor to performance mode, set quantum to 800 using the command below, and played “Demosong - Danoise - LFO.xrns”, xrun occurred. Setting it to 1024 seems to resolve the issue.
pw-metadata -n settings 0 clock.force-quantum 800
This might indeed be a problematic.
Due to excessive latency, it is not possible to perform live guitar playing or similar activities simultaneously on the same machine.
Interesting. Yes, this is the same problem that I have. Although increasing the latency does help, setting it higher than 256 starts making real time playing difficult.
Do you experience any difference if you do the same thing with Renoise 3.4?
In V3.4.4, it seems xruns don’t occur even when quantum is set to 96.
I think it could be used for live guitar performances, but considering RenoiseTools compatibility is a tricky point. I can’t live without Paketti.
Looking only at the above, one might say efficiency dropped by about 10 times in V3.5.
It would be great if the bottleneck in V3.5 could be made optional.
Alright, so we have separate confirmation by two people now. That’s great, it’s a step towards getting more attention to this. I’m updating the title again.
This does sound a lot like what I was getting trying to get PipeWire-JACK working on CachyOS/Arch before giving up, just errors piling up even though pw-top looked fine. Spent days trying all sorts of things with no luck (as detailed in another thread) - even a single track with my RME interface set to a silly 1024 was a complete mess.
Although I did download the Reaper trial to make sure it wasn’t a Renoise issue and that didn’t seem stable either, so maybe it’s not related at all.
Does this issue not occur on Windows or macOS?
Is there an environment or configuration where this problem doesn’t occur on Linux?
Can you record live guitar through plugin FX in any DAW, including Renoise, while playing a Renoise project on the same machine, and also perform real-time MIDI or audio recording using a MIDI keyboard, all without issues (i.e., with latency kept within about 5 milliseconds)?
Considering there are no similar reports, it’s likely possible to play Renoise projects on Windows or macOS without drastically increasing latency or causing audio glitches.
Why is this issue occurring on Linux?
The features added in 3.5.0 are extensive, but the significant increase in latency is a critical issue for real-time MIDI and audio recording and performance.
I’m not sure, but could it be caused by the following module newly added in 3.5.0?
I have a gut feeling about performance on macos, nothing serious though… Seems to me that somehow performance degraded a little bit. Strange stuff happening, like a song stutters at 8ms, but plays at 6ms… Or songs used to play nicely with 4ms now need 6ms. Maybe it is just the shitty macos update 14→15. macos on the other hand is a whole different story, with its workgroups api stuff.
Okay, so I believe it may be related to the pipewire setup or the way Renoise interacts with pipewire.
So I got fed up with pipewire, and removed it from my debian installation…using oldschool pulseaudio and using jackd2 instead for renoise.
It works as expected, even since 3.5 I am able to drive lower latencies with jackd than Renoise could cope with before. Like ultra low-latency below 1-5ms with a realtime kernel which was not possible before, though stressing the CPU may result in dropouts quickly without realtime hardened kernel. I can drive dblue-tension with like 5+ms latency on non-rt kernels without deeper system tunings with jackd2 and realtime/interrupt priority settings enabled.
Have you guys configured realtime priorities properly? I don’t really remember what was the fault in pipewire, but I also remember renoise had very bad performance on pipewire/jack unless I used specific settings, and it was maybe related to pipewire addressing generic/mixer devices and not driving the interface in true realtime mode like jackd2 does via alsa.
@OopsIFly: I encountered the problem with Jack2, not with Pipewire, so that’s not the issue here.
And the realtime priority configuration is definitely correct, because Renoise 3.4 runs rock solid. I can also see through process inspection that Renoise is getting realtime priority on its threads.