OSX El Capitan 64bit: Audio stutters/lags @ 50-60 cpu load

Really calling out taktik and rest of the team for investigation and help!

I just migrated finally to latest os x el capitan (my specs: core i5 mbpro with 8gb ram and ssd, dual monitor setup via thunderbolt, ni komplete 6 audio interface), installed r 3.1 final x64 and all the necessary plugins (64bit versions).

So i’ve tried to run one my heavy cpu tracks there and here is the deal - previous version of this track was running on os x mavericks and renoise 3.0/3.1rc x32 build with 32bit plugins (@88 khz samplerate), there was a a place in the middle of the track (which contains a lot of automation and sample modulation) where it was very heavy on cpu (around 70-80%) and everything started to lag, that was kinda ok with me. Today i’ve tested this on a new system - i loaded up the track, replaced all necessary plugins with 64bit versions and the result was shocking - when cpu loads above 50% or more the audio starts stuttering and laggin (gui is still pretty fluid no lag here btw). I do not use any kind of bridging, os x AppNap feature is turned off at the system level and per app, no other whistles here, system is crystal clear. I also tried to change my buffer settings from 32ms to max avail 48ms, no luck here too.

As i’ve read from here on site, x64 builds supposed to work better with some benefits than x32. So what i’ve described (audio stutters at 50+% !!! wtf) is not acceptable performance at all!

Also, previously i’ve had issues with FabFilter’s Pro Q2 on 32x builds, when plugin gui is open audio starts to stut n lag, so on a new system i’ve updated the plugin to the latest version and that crap still occurs. Other gui heavy plugins also affects renoise performance alot (which is not happening in Logic Pro X for example or Reaper, even with Pro Q 2!!), so whats happening here renoise team??

Can anyone here in the team explain or help me to solve those issues somehow??? Anyone else have those issues, any solutions??? This is really important and urgent and i dont want to start any rant here (like i did days ago mentioning the strange new filters behaviour), i just want explanations and a proper solution.

UPDATE:

I tried to run the project @ 44khz sample ratio, when cpu hits 54-60% audio starts to stut-n-lag too! =(((

UPDATE 2:

This is completely weird - so i went to the fabfilter forum just to see if anyone there complaining about gui/audio lags with their plugins in different daws (but i have none in logic!) and found an explanation/solution there - their plugins are now all gpu accelerated and sometimes behaviour different in various DAWs, so they propose to turn off gpu acceleration via terminal command (http://www.fabfilter.com/support/faq/18/how-can-i-disable-graphics-acceleration-on-my-computer), so i’ve restarted renoise, loaded the song, looped the most cpu intensive part of the track, turned on the mixer view, the cpu peaked at 60-70% now and the renoise audio and gui started to stutter and lag, BUT then i opened the Pro Q2 plugin gui (so the plugin window now closing some part of the renoise mixer view) and audio stuttering and lag mostly gone and that @ 74+% cpu load!

Really guys, whats happening here with renoise gui/audio handling?

Here is the video>

https://youtu.be/IrhC2NTMr1Y

you can clearly see here the scenario, press play cpu hits 70% audio stutter/gui lag occurs, i open the pro q 2 gui window, the cpu gets more heat but less audio stutter/gui lag.

At the end this post is becoming somehow related to my previous one (https://forum.renoise.com/t/osx-poor-gui-performance-in-combination-with-plugins/45164), but there was not comments by devs at all and FFX’s solution to alternate info.plist file did not worked.

UPDATE 3:

I’ve tried to install 32bit renoise build and see how the stuff going on there - and goddammit it works as it should, it works as on my old osx mavericks setup (as described above).

Well, I can somehow confirm that the 64bit build has at least a slightly slower framerate than the 32 bit build, here on Mavericks 10.9.4. Would be nice if all those stutters and lags could be history some day…

Thanks god I did not upgrade to El Captain yet. I think I will wait for 10.12.

Thanks god I did not upgrade to El Captain yet. I think I will wait for 10.12.

I’m with you. I am on Yosemite and I don’t dare to upgrade, there’s too many horror stories.

Well, I can somehow confirm that the 64bit build has at least a slightly slower framerate than the 32 bit build, here on Mavericks 10.9.4. Would be nice if all those stutters and lags could be history some day…

Thanks god I did not upgrade to El Captain yet. I think I will wait for 10.12.

i’ve had issues with x64 build on mavericks too btw, not that disastrous but anyway. so i thought they finally get ridden of that in r 3.1… nothing wrong with el capitan, works stable and fast.

I’m with you. I am on Yosemite and I don’t dare to upgrade, there’s too many horror stories.

i stayed on mavericks 10.9.5 for a long time, so when el capitan came (i missed yosemite because it was raw crap) i was reading all those horror stories too, so i decided not too update until Apfel Corp iron things out. So i installed El Cap 10.11.3 from scratch on a new ssd and everything is superstable and superfast (surely i turned off all those bells n whistles).

people complaning that Logic works like crap on el cap, not sure what they talking about, but mine works a lot faster and snappier than on mavericks.

Seems Steve Jobs wrath and quality control is sorely missed.

i stayed on mavericks 10.9.5 for a long time, so when el capitan came (i missed yosemite because it was raw crap) i was reading all those horror stories too, so i decided not too update until Apfel Corp iron things out. So i installed El Cap 10.11.3 from scratch on a new ssd and everything is superstable and superfast (surely i turned off all those bells n whistles).

people complaning that Logic works like crap on el cap, not sure what they talking about, but mine works a lot faster and snappier than on mavericks.

Hm, maybe I should try an update one day then. :slight_smile: When renoise will work better.

ANYONE?

… Yeah, this is annoying. I have similar issues now with some projects with CPU load over 60%. For example melda mpowersynth. It’s really strange, at song begin (song from osc83, mpowersynth only) renoise heavily stutters (at less than 60% load) for some seconds, but then the stuttering disappears, although now there are even more instances playing. Later, strange stuttering sometimes appear, neither renoise CPU indicator nor activity monitor show extensive load.

I can send the file to the devs if they want.

Only vsts seem to be affected, but not renoise instruments (see benchmark thread, I can run crazily many instruments at 96% load without any stuttering)

The gui and audio process should be completely independent. Or maybe is it again that frame buffer renoise gui problem, so if renoise floods the frame buffer with hundreds of useless refreshes and now a plug in also requests heavy refreshes, that osx won’t handle that flood anymore?

Ransom, can you try to lower the number of processing CPU cores from 8 to 6 (so one physical core is not processing) and then test again?

… Yeah, this is annoying. I have similar issues now with some projects with CPU load over 60%. For example melda mpowersynth. It’s really strange, at song begin (song from osc83, mpowersynth only) renoise heavily stutters (at less than 60% load) for some seconds, but then the stuttering disappears, although now there are even more instances playing. Later, strange stuttering sometimes appear, neither renoise CPU indicator nor activity monitor show extensive load.

I can send the file to the devs if they want.

Only vsts seem to be affected, but not renoise instruments (see benchmark thread, I can run crazily many instruments at 96% load without any stuttering)

The gui and audio process should be completely independent. Or maybe is it again that frame buffer renoise gui problem, so if renoise floods the frame buffer with hundreds of useless refreshes and now a plug in also requests heavy refreshes, that osx won’t handle that flood anymore?

Ransom, can you try to lower the number of processing CPU cores from 8 to 6 (so one physical core is not processing) and then test again?

i’ve tried this days ago - no luck.

This is complicated - depends on many things. Don’t worry, we’re watching, trying to collect more informations and are testing the issues on our own before we give answers to such things. No one is ignoring you here, but wild speculation and !!!s also don’t help.

Did a few tests by my own in the past days on OSX El Capitan, and I can confirm that newer OSX OSs indeed tend to be a bit more “sloppy”, a bit less stable at high audio CPU loads than older ones. What exactly causes this is hard to say, but in general it seems that later versions of OSX seem to give certain GUI operations more and more priority, which then starts eating up resources for real time audio threads at some point. I guess that they are doing this to create in general a more smooth user interface experience, but this also may be a very specific problem the way the Renoise GUI works and may also have to do with the retina (in)compatibility support.

But not only the GUI may influence the stability of the audio processing, it also depends on how the audio itself is processed. The CPU usage displayed in Renoise and Activity Monitor actually is the !average! CPU usage only. This means something (a native DSP of Renoise or some plugin or some other audio processing in Renoise) still may !temporarily! use more CPU than that and temporarily create a click only. So if you hear a crackle it’s quite likely that the CPU usage went above 100% for a very short moment only. And as noted before, this either could be caused by the operating system or by a DSP processor. DSPs which do things like FFT processing (for example convolution processors) are known to create huge temporary CPU peaks, cause they are processing audio in “blocks”.

What exactly the problem in your case is is hard to guess, and could only be found out by looking at a specific song on a specific system.

If you are looking for a general solution to the problem, do the most obvious thing:

  1. increase the audio latency (the higher the latency, the less likely it is that a temporary CPU peak creates a click - and, the higher the latency the more efficient many audio DSPs can be processed)

  2. lower the GUI frame rate (if GUI processing really is causing the clicks)

This is complicated - depends on many things. Don’t worry, we’re watching, trying to collect more informations and are testing the issues on our own before we give answers to such things. No one is ignoring you here, but wild speculation and !!!s also don’t help.

Did a few tests by my own in the past days on OSX El Capitan, and I can confirm that newer OSX OSs indeed tend to be a bit more “sloppy”, a bit less stable at high audio CPU loads than older ones. What exactly causes this is hard to say, but in general it seems that later versions of OSX seem to give certain GUI operations more and more priority, which then starts eating up resources for real time audio threads at some point. I guess that they are doing this to create in general a more smooth user interface experience, but this also may be a very specific problem the way the Renoise GUI works and may also have to do with the retina (in)compatibility support.

But not only the GUI may influence the stability of the audio processing, it also depends on how the audio itself is processed. The CPU usage displayed in Renoise and Activity Monitor actually is the !average! CPU usage only. This means something (a native DSP of Renoise or some plugin or some other audio processing in Renoise) still may !temporarily! use more CPU than that and temporarily create a click only. So if you hear a crackle it’s quite likely that the CPU usage went above 100% for a very short moment only. And as noted before, this either could be caused by the operating system or by a DSP processor. DSPs which do things like FFT processing (for example convolution processors) are known to create huge temporary CPU peaks, cause they are processing audio in “blocks”.

What exactly the problem in your case is is hard to guess, and could only be found out by looking at a specific song on a specific system.

If you are looking for a general solution to the problem, do the most obvious thing:

  1. increase the audio latency (the higher the latency, the less likely it is that a temporary CPU peak creates a click - and, the higher the latency the more efficient many audio DSPs can be processed)

  2. lower the GUI frame rate (if GUI processing really is causing the clicks)

  1. latency is maxed out to 46ms @ 88.2 khz, its max avail for my audio interface (ni komplete audio 6), also tried with built in audio and friend’s UAD Twin , all the same =/

  2. tried to limit to 24fps/30fps, no much luck here too.

Is this somehow related to that new graphical api called Metal?

I don’t really get why the system gui should affect the renoise gui, because renoise doesn’t seem to use the new mechanisms anyway. I would guess it’s again that old problem that renoise floods the frame buffer or something. So a renoise gui problem.

@RANSOM: that sounds pretty extreme. As noted above, could you please share the song file with us, so we can have a look at this here? We else can only speculate wildly - don’t think that helps. Maybe it’s something else after all…

@RANSOM: that sounds pretty extreme. As noted above, could you please share the song file with us, so we can have a look at this here? We else can only speculate wildly - don’t think that helps. Maybe it’s something else after all…

check your PM please.

Thanks. Will take a while until I’ve collected all the plugins that you’ve used in that song. Else everything looks OK in the song. Without plugins it’s actually very light on the CPU, so it seems that most of the power is consumed in plugins.

Have you tried if minimizing the Renoise window results into less crackles? All (critical) GUI processing is bypassed when minimizing/hiding the UI, so this would give us a hint if/that the GUI processing really is the problem here.

Also, are you sure that no plugin is bridged? Bridging will cause a noticeable overhead, not much, but definitely more overhead than running 32 bit natively in a 32bit application.

Maybe it’s caused by denormal numbers? For test you could add a noise fx to each channel as first fx…

Thanks. Will take a while until I’ve collected all the plugins that you’ve used in that song. Else everything looks OK in the song. Without plugins it’s actually very light on the CPU, so it seems that most of the power is consumed in plugins.

Have you tried if minimizing the Renoise window results into less crackles? All (critical) GUI processing is bypassed when minimizing/hiding the UI, so this would give us a hint if/that the GUI processing really is the problem here.

Also, are you sure that no plugin is bridged? Bridging will cause a noticeable overhead, not much, but definitely more overhead than running 32 bit natively in a 32bit application.

I twice checked all the vst/au i’ve used - all of them x64, no bridging at all, even those Fabfilter pro-q running in non GPU-powered mode (because gpu-enabled fabfilter causes hell of crackles/stuttering in Renoise, no in Logic for example). Also you must’ve mentioned that there is no VSTi at all, because i’ve rendered them all to instruments. Also notice that this song is running @ 88.2 samplerate.

And finally, i’ve tried to minimize the gui - ALL STUT/CRACKLING IS GONE. Also if i just resize the renoise gui to minimum those issues are gone too.

UPDATE: I’ve also tried on various other cpu heavy tracks, the result is the same - weird crackles at 55-60-70 cpu load, but if i minimize renoise gui CRACKLES/STUTTS are gone.

So this seems to be the proof that the Renoise GUI is responsible for the dropouts.

So this seems to be the proof that the Renoise GUI is responsible for the dropouts.

Kinda like it is. There is something i guess…something in renoise graphics engine which do not utilise os x coregraphics stuff, or implemented in a very different way and need to be fixed/rewritten. Anyway i cannot claim those kinda statements here about this issue, me not a coder at all (some max/msp coding and knowing basics of os architecture/frameworks not counting at all). But it’s a fact now - something is wrong with that, since Mavericks i guess.

We’ll look into this. If the 32 bit version of Renoise works better on your setup, then please use this one for nowinstead. Or try working with lower sample rates and render at higher ones only.

As mentioned previously, this is topic very complex, depends on many many things, so there quite likely will not be a “fix” for this, but it’s more about about making things a bit worse or better.


Btw: You both (RANSOM and FFX) sound a bitreproachful lately. We never have ignored such issues in the past, but always have been interested in getting such things fixed - if somehow possible. So where does this attitude come from?

If you are unhappy with Renoise in general, I won’t be able to fix that. Use it for what it can do and don’t wait for it to become what you hope it could be.