Possible performance problem R3.1 + powerful PC

For a long time, I’ve suspected something rather strange with Renoise, at least since the release of version 3.1.0 x64 (Win 10).

Using the same PC always. Renoise sometimes goes faster, and sometimes slower (below I put the characteristics of my machine).This has been confirmed using my GT16-Colors tool with an internal tool module called “TNC”, which uses a very fast timer (5ms).I have done tests of all kinds, ruling out that it is some problem of hardware or drivers.

The problem is very subtle but it is noticeable if you look closely at the speed when passing the patterns when playing any song.What happens, is that in new starts of the executable of Renoise, sometimes has some lag in such reproductionand sometimes it works finest.How have I checked?I used my tool GT16-Colors (the TNC module tool) with the same settings and I use a reference speed (700 BPM 8 LPB), no matter the song (using only samples or plugins (VST/VSTi)), nor has anything to do with the use of tools.

I have done a lot of testing, both hardware, energy options, overclock, etc, and this subtle problem is still there. Imagine:

  • Day 1:I turn on the PC and run Renoise and in my module tool TNC of GT16-Colors works without any reading error at (700 BPM 8 LPB).I close Renoise and shut down the PC.
  • Day 2: I turn on the PC and run Renoise and in my module tool TNC of GT16-Colors worksreading errors at (700 BPM 8 LPB, or even 300 BMP 4 LPB)…It seems that Renoise runs slower than day 1, with a very subtle little lag…
  • Day 3:The same as day 1, all perfect.
  • Day 4:I turn on the PC and run Renoise and close Renoise to make several tests without modifying any Renoise settings. In the first starts of Renoise worked with that little subtle lag. But in the last run it already worked fine.I run Renoise again and it works fine again.
  • Day 5:The same as day 2, with taht little subtle lag.

To detect the lag I have done tests of visualization, without using tools or plugins.In short, the case is that the displacement of the pattern in reproduction sometimes works fine, and others have a small lag.I’ve done a lot of testing already, and I rule out it’s a hardware problem.

Does Renoise internally have a problem getting the most performance?What can be the cause that sometimes works fine and in others with a small lag that is visually appreciated?

The tested PC:

  • MB: GIGABYTE GA-Z170X-GAMING G1.
  • CPU: Intel i7 6700K, 4 physical cores and 8 threads (min 800MHz, max 4000MHz, turbo 4200MHz) (with or without overclocking, often fixed or varied, I have tried everything. In all tests CPU usage has never exceeded 10% according to the upper right panel of Renoise).
  • RAM: Corsair 4x 32GB DDR4 (dual channel, 3400MHz).
  • GC: Shapphire 6950 x 2 (Crossfire or not, I have tried both).
  • SC: Creative Sound Blaser ZxR dedicated (with Direct Sound and Asio. I have tried both also).
  • PSU: Antec 1000W
  • SO: Windows 10 Pro x64 (Installed on a SSD)
  • Renoise: v3.1.0 x64

I rule out that it is hardware, apart from all the tests that I have done, it is the fact that the PC is very fast.But, that does not prevent Renoise from working differently as he pleases.Is it possible that there is an optimization problem? What can be the cause?Does Renoise have some internal regulator or something, that can test that it works differently with the same machine?

Does something similar happen to someone?

Thanks!

Note : to clarify, I have also done tests without modifying the Renoise configuration preferences, and the problem persists…

AFAIK a 5ms timer is not possible in LUA, just like in javascript. The minimum is around 20ms or so. Also the interpreter doesn’t run exactly.

  1. I can’t find the details in your text on when/how it is slowing down, or how you have tested it.

  2. I’ve previously had some problems with clicks and pops at pattern boundaries. At the time, this seemed to be very related to the soundcard or its driver.

AFAIK a 5ms timer is not possible in LUA, just like in javascript. The minimum is around 20ms or so. Also the interpreter doesn’t run exactly.

I suppose you mean renoise.tool().app_idle_observable

Is possible to use add_timer :https://forum.renoise.com/t/solved-help-check-notes-with-follow-the-player-position-in-patt-ed/47685

In fact, maybe it works even with 1ms (1s/1000), but at very high speed it can return errors, for example data reading.

  1. I can’t find the details in your text on when/how it is slowing down, or how you have tested it.

  2. I’ve previously had some problems with clicks and pops at pattern boundaries. At the time, this seemed to be very related to the soundcard or its driver.

The explanation is very simple.Play any song at a high speed (for example BPM 700 and LPB 8 or higher) to see it with the eyes, with the newly installed renoise default settings (with playing position activated (key “scroll”)).It is only necessary to look with the eyes at the fluidity of the movement of the patterns during the reproduction, Sometimes it is perceived that it goes to blows, with small intermittent delays.I thought this was normal. But after trying my tool (GT16-Colors, TNC module tool),I have noticed that randomly performance decreases and sometimes runs very fluid.It does not depend on the structure of the song, and can happen with a very low CPU load, below 2%.

If this happened with a high CPU load, I would see it normal.But it happens with a very low load.It happens the same way using DirectSound or Asio.I have come to reproduce the same song with the displacement of the very fluid pattern, but also the same song with the displacement to blows, without changing anything of the configuration of Renoise and of Windows 10.

Something happens automatically that sometimes causes a performance drop in Renoise.It is not the cause of any tool, nor any plugin.I do not know if it is related to the terna CPU+RAM+Chipset, or because of the sound card.

The default configuration of Renoise:

7399 r3.1-default-preferences.png

  • In Preferences/Audio/Latency(ms) is 35. Modify this option does not solve the problem.
  • In Preferences/GUI/Global: Limit frame rate to is 60 fps (just as it refreshes my monitor).Disabling this option also does not solve the problem.
  • Modifying any feature of preferences does not help to solve the problem.

The sound card I use is theCreative Sound Blaser ZxR dedicated, which I suppose has good performance. I can use a wireless USB headset to change the output device sound in Renoise, but it sure is slower than my PCIe sound card.

Is it possible that it has to do with access to RAM?

Overall, not a big problem, but I’m talking about a high performance PC. Renoise should go like a bullet always, even at maximum speed!

FYI, timers are not exact according to the documentation (I think this was mentioned in your recent thread also).

Does it happen “randomly” both with and without your tool installed?

(If it only happend when your tool is installed, a plausible explanation could be that timers tend to trend towards either “direction” within their “tolerance”. When the trend is that the timers are fast, this would require more CPU and make other things more sluggish)

FYI, timers are not exact according to the documentation (I think this was mentioned in your recent thread also).

Yes, I am very conscious. I think the problem is unrelated here.

Does it happen “randomly” both with and without your tool installed?

(If it only happend when your tool is installed, a plausible explanation could be that timers tend to trend towards either “direction” within their “tolerance”. When the trend is that the timers are fast, this would require more CPU and make other things more sluggish)

Yes,I have done several visual tests with newly installed Renoise clean, not including any tool, and any plugin (VST/VSTi).It seems to be a theme between Renoise’s relationship with hardware and drivers… and optimization?

Regardless of whether I use my tool or not, the CPU load does not exceed 2%, sometimes presenting these small lags.Renoise uses very little processor and presents lags?It may not be a sound issue, and yes the Renoise GUI, the graphic section.It has nothing to do with my tool, it happens the same without being installed.

Randomly, the reproduction is slightly heavier, perceptible even graphically.

A little more detail.When Renoise make these small bumps or lags, is also perceptible graphically at low speed (for example BPM 200 & LPB 8).Fluency is not perfectly constant.Sometimes it has small lags.You have to look good with your eyes.So I ask if something goes wrong here related to some optimization section of Renoise.

The problem is very subtle but it is noticeable if you look closely at the speed when passing the patterns when playing any song.What happens, is that in new starts of the executable of Renoise, sometimes has some lag in such reproductionand sometimes it works finest.

“Reproduction” - are we talking UI / scripting performance or song playback here? Sound like you mean UI.

The only part that really needs to be constant and smoothly running in a DAW is the audio. And the load on the CPU for audioprocessing is not constant - it changes with e.g. the intensity of parameter automation (some plugins really carry a penalty for this), or when jumping around the project timeline and switching patterns.

So, to avoid drop-outs, other parts of Renoise (UI, scripting) might be deemed less important at any given moment. If you’re experiencing that other parts are sometimes not updated as frequently, that would most likely be the reason.

The scripting API itself has some hidden processes that are running, such as garbage collection (GC). This kicks in every now and then and clears up unreferenced variables that have been created during the execution of your script. But it doesn’t carry much of an impact, unless you are creating huge amounts of throwaway data.

And while it’s technically possible to fiddle around with the GC features, for example to raise the frequency of collection or disable it entirely, it’s not really recommended to do so. The default settings are usually the ones that work best across the widest possible range of systems.

Overall, not a big problem, but I’m talking about a high performance PC. Renoise should go like a bullet always, even at maximum speed!

I’d recommend optimizing the whole PC towards audio. It used to be a “big thing”, but nowadays computers are vastly more powerful and this step has become less important.

Still, there are so many things that can cause temporarily dropouts in performance. A software that decides to update itself in the background? Scheduled harddisk tasks?

All of this will affect the Renoise performance, which in turn will affect how much CPU time Renoise is doling out to things like lua scripts…

This is also why I recommend the idle approach - as audio is the top priority, your scripts can never expect a stable update rate.

It’s basically out of your control. I’d rather write scriptsthat deal well with any updaterate. But this will add a bit of complexity to the script, of course.

“Reproduction” - are we talking UI / scripting performance or song playback here? Sound like you mean UI.

Song playback (in Pattern Editor, Matrix, Mixer, Auotomation, all).If there is a knock or lag, it can be appreciated subtly by looking at any moving Renoise panel, like the Matrix or Automation Pane.It is something graphical that also influences the speed of the tools with fast timers, if they are activated.I have no sound problems, the sound works fine.

I’m sure it has nothing to do with the scriping API for tools,Is the way Renoise works to update graphicallythe content constantly, which at the same time can cause also show the same lagsin tools with timers to graphically update the GUI of a tool.

In short, Renoise GUI may not always work in real time, causing minor delays or lags graphics.If this is the cause, could it be revised for a future version?

Today there are very powerful home computers, with graphics cards also very powerful (and monitors). Is not possible better synchronization between audio and video?

Probably more of a question/thread for Taktik Raul :slight_smile:

Anyway just as a ‘side line tid bit’ I put this in the formula device on a track (as a very crude ‘stress tester’):

Attachment 7402 not found.

Just to see how high I can make the for loop variable ‘i’ before Renoise transport/audio doesn’t like me anymore (switch off CPU overload prevention in the audio preferences!) I get the CPU load to close in on around 99% (transport slower stuttering/audio breaking up) and also switch between single CPU and multi CPU.

For realtime audio it is the usual technique to privilege the audio/midi thread MUCH above everything else, including the audio program’s event and gui processing. You will want dropout free audio, even if the gui is down to 2 fps. Especially in live scenarios. Accepting audio glitches to minimally raise gui fps is a thing games would consider, not any daw

I use renoise in linux, and there you can actually watch and manipulate the audio/rest thread privileges. It is normal for me to privilege sound card/audio processing the highest, even above certain os/system tasks, so nothing can steal my dsp performance, only the other way round. Gui is not so critical, and renoise’s gui actually seems rather slim for me, though the gui/event stuff has its little glitches that can make it choke now and then (think about adjusting the loop markers to the left of the sequence matrix with the mouse while playback, and some other things…). Also be aware that a big powerful 3d graphics card with 5 extra power connectors won’t be any help for running renoise graphics, they are most probably very much cpu bound in nature so hardware acceleration would probably make only minimal difference between current standard low end and high end graphics cards.

I’ve not encountered any strange performance hogs yet, at least no unexpected, and when I did it came to system tuning to fix it, not on the renoise side. And I have a strong PC and do silly things like trying to build neuro type instruments with renoise native dsp, without any resampling…everything in realtime, going towards the 70% mark of maxing out a core with the instrument where it would start to become too heavy at around 80%. So…I’m used to watching the cpu usage number, and haven’t noticed any strange jumps between sessions with it yet, other than maybe when I forgot to disable the general system audio bridge to my realtime audio mode, which would then hog some perfomance.

Maybe your problem is on one of the following sides, try to rule them out:

  • some tool going haywire, encumbering the event/gui thread

  • some vst plugins not behaving so nice depending on phase of moon…

  • some os/system/malware task privileged above renoise gui/audio threads, if it is just running it will steal cpu power from renoise

  • general realtime privilege configuration issues with your system, bad interrupt actions happening or such stuff that is only fixable by your hardware’s manufacturer

  • or you indeed found some bug in renoise

Probably more of a question/thread for Taktik Raul :slight_smile:

Anyway just as a ‘side line tid bit’ I put this in the formula device on a track (as a very crude ‘stress tester’):

attachicon.gifslow.png

Just to see how high I can make the for loop variable ‘i’ before Renoise transport/audio doesn’t like me anymore (switch off CPU overload prevention in the audio preferences!) I get the CPU load to close in on around 99% (transport slower stuttering/audio breaking up) and also switch between single CPU and multi CPU.

On my PC, I have tried your slower() on a track and the CPU loads at 31% fixed. I mean with my comments that perhaps the hardware of a powerful PC has such a high performance that it does not seem logical that Renoise sometimes works with lags.

with:

function slower()

for i=0, 3000000 do end

return 0

end

work CPU 91% ~ 90%

Without doing anything, it marks me CPU 0.3%…By the way, he had never tried it!!! :slight_smile:

I know it is defensible that audio should take priority over graphic performance. But on powerful PCs, it should go like silk.

Maybe your problem is on one of the following sides, try to rule them out:

  • some tool going haywire, encumbering the event/gui thread

  • some vst plugins not behaving so nice depending on phase of moon…

  • some os/system/malware task privileged above renoise gui/audio threads, if it is just running it will steal cpu power from renoise

  • general realtime privilege configuration issues with your system, bad interrupt actions happening or such stuff that is only fixable by your hardware’s manufacturer

  • or you indeed found some bug in renoise

When I have done my tests, I have discarded all these external cases of Renoise.I do not know if the current operating system influences, but in the monitor of resources of Windows the processor never rises of 10%, it is always below.Renoise, using very little CPU, presents subtle lags in playback, even on powerful PCs.In fact, it has always been this way with this version, only that I had not realized until now.What I find strange is that it is not always like that.Seems a random behavior.

Then I wonder if Renoise is optimized to take full advantage of the resources offered by the current powerful hardware, (Powerful processors with several physical cores, fast ram memory, graphics cards of last generation, etc).Renoise is not a game. Precisely for that, Renoise should be able to show the graphics perfectly fluent.Nowadays games suck a lot of resources.

Maybe something internal Renoise does not work like a millimeter clock?I get the feeling that something subtle generates a small bottleneck, translated into small subtle lags, which can be appreciated in the Renoise GUI and that may perhaps influence the API available to create tools, especially those that have to do with a tool GUI.But deep down, for me the tools do not matter so much. I prefer that internally Renoise works like silk, the rest is secondary.