Laggy spectrum analyzer type plugins high Sierra

Installation & Configuration Mac OS X
#1

Anyone else have issues with ardour or Mixbus, like at first everything is fine but then as I get s mix going eventually plugins that show spectrum analyzer I notice it’s laggy and stuttering and not smooth, I don’t have this issue with Mac OS Mavericks on my other drive, what’s going on. I also use Mixbus and it’s the same, I’ll have to retest with Ardour to make sure but I unno why it seems this way

#2

Can’t say I have noticed it, but I don’t use RTAs much when mixing in Mixbus/Ardour.

         Seablade
#3

This could be caused by Apple changing important elements of their graphics system. It has happened before, and it will no doubt happen again. Deciding if it has happened here is much harder to tell.

#4

I understand probably Apples fault, there was a plugin that shows the output in the plugin meter and it’s is laggy when the levels are jumping, I do find all these anoying but it works better in older Mac OS operating systems. I guess I can’t expect to keep using the latest OS with Mac,

#5

Well technically Mojave is now the latest isn’t it? Either way I would never recommend updating OS X when it comes out for those of us working with audio. It just never ends well. But at this point we can’t really argue that it is to fresh, again not sure what is causing it, it may even be something in the plugin itself instead of Ardour, but it is hard to tell as Paul said.

          Seablade
#6

Around the time of Mac OS X 10.9 something changed that affected the way the graphics system behaved / behaves - it appears as if the timing got much more strict, e.g. all redraws had to be accomplished within one video frame for performance to be consistent and reliable. This is actually quite difficult to guarantee with a host application, and possibly many other plug-ins all competing to update their UIs in realtime (using a variety of different toolkits and methods). The manifestation is / was typically realtime meters and other regularly updated components of the host / plug-in UIs might lock up or freeze temporarily while e.g. a plug-in control was being moved (or something which required a lot of redraws). Essentially if something was doing a lot of heavy graphics processing and took longer than the available time, the ‘fairness’ seemed to become much less predictable, leading to e.g. jumpy or erratic updates of some / other UI components. There was a lot of debate about it at the time (many plug-ins / host applications affected), but information from Apple was quite limited. FFT analysers (especially if they don’t use graphics acceleration directly… which is another can of worms… can be some of the most graphically intensive plug-ins)

#7

I understand, Mojave is the next update now, I am fairly disappointed in Apple for making things so complicated, they have too much control and it doesn’t help everyone. Really looking forward to leaving the Mac OS operating system one day, I had to use Mac OS Mavericks for a long time cause it was more stable for all my programs for music. But I avoided going online with it since there’s no more security updates and support, (Sigh) I’ll figure something out, I don’t like windows and my only other option is Linux which I do like very well.

#8

mike - that explanation isn’t really correct.

There are two existing issues with graphics on macOS/OS X.

  1. the prohibition on excessive redraw rate. The graphics stack doesn’t care how long the app takes to redraw (because it happens asynchronously with respect to the actual vblank cycle). But it does care about apps which request redraws too often. So care has to be taken to ensure that an app (with any contained plugins) does not do this. The part here where you’re correct is that if a plugin queues its own redraws (and some of them do … looking at you, Waves and PSP), then this can trip the “redraw” limit, which will apply to the entire application, and does indeed make the entire app graphics seem sluggish. There are some cool developer tools (or at least, there were) to measure this and monitor it.

  2. colorspaces … converting between colorspaces is really slow, and apple changed some things around 10.8 or 10.9 that made a lot of otherwise perfectly well behaved applications suffer from really bad graphics performance. Their default colorspace differed from the system one, and the conversion is incredibly slow. The lead developer of Reaper has some incredibly informative posts about tracking this down and strategies to work around it. We’ve done what we can within the context of GDK and Cairo to avoid this, but it is also possible that Apple has changed something like this once again.

#9

@paul: Thanks for the clarification (actually its likely that came out of an email conversation between myself and Justin at Reaper about addressing these issues at the time. I can’t quite remember, but I know there was some discussion and I did a lot (e.g. too much) investigation of this when it occurred - I think we’re actually saying the same thing, but (as usual) I’m simplifying it.

  1. Redrawing happens asynchronously with respect to the VBlank - well, yes, though if you use GL you can change that, but lets assume that’s true for most (bitmap) blitting. Anyway, that’s not the issue…
  2. ‘Requesting redraws too often’ - exactly - suppose your app / plug-in queues redraws, for non-interactive controls, at some internal ‘frame rate’ of e.g. 50Hz, then, if all your drawing completes within the time for a frame its fine. If however, it takes too long, then another redraw might get “queued” up / triggered immediately the previous one finishes - which translates to “requesting redraws too often” (there’s actually not much of a ‘queue’, I think its really just a flag that gets set on the NSView, which is inspected at the top of the runLoop to trigger a ‘drawRect’ call on the view if required. In older versions, this just resulted in an occasional drop in frame rate and wouldn’t normally be noticed. The thing that exacerbated this, was as you point out, the colourspace issue, though that’s not the entire story.
if a plugin queues its own redraw
They all do. You can't rely on the host, and not all hosts will do this for you. The normal method is to do drawing to an offscreen bitmap, and then copy the required area to the view when a call to 'drawRect' happens on the view. That call may be triggered by the plug-in UI itself if it has something to update, or by the system if / when part of a window becomes visible etc That's fairly standard. Plug-ins which use openGL will do things differently.

(Disclaimer… While I don’t / can’t know exactly how the OS X drawing code works internally, out of necessity I developed my own graphics ‘engine’ and ported it across Windows GDI, Linux X11 and Mac OS X coreGraphics, and created my own openGL based renderer - from the ground up - for all those platforms too, so you can be sure I’ve had to deal with a lot of (quite deep) graphics code - I often do more graphics programming than DSP when developing plug-ins - which is a whole other discussion about plug-in UIs etc. - I also did some game development / emulation for my own amusement too, which involves a lot of pixel wrangling as well - but that’s also a whole other story… which in part goes all the way back to early 8Bit machines)

#10

My impression was that macOS doesn’t care how long your redraws take. The developer tools will let you remove the redraw rate limit, and you will see apps getting above 80 fps (i.e. they can redraw plenty fast). Put the limit back in place, and they will be throttled back to whatever the limit is set to. Obviously, taking too long to draw is also a problem, but the specific change that Apple made was to rate limit too-frequent redraws, not too-slow ones.

BTW, it’s precisely the “copy from off-screen bitmap” that triggers the colorspace issue (that’s typically where the conversion has to take place). If you can force the offscreen surface to use the same colorspace as the “hardware”, all is fine. Except … this isn’t always easy.