People keep reporting that graphics issues are causing pops and clicks. And it changes with resolution, or frame rate, or some other factor.
As a programmer, this has never made much sense to me. The audio and the graphics run on different threads – why would they interact? Especially if the audio is running on an elevated priority level, how could the gfx slow it down, even if it tried to? VCV itself doesn’t have any synchronization the should be affected like this (at least at casual glance).
I’ve tried to cause problems by doing silly things with the graphics, including sleeping for long periods of time, but have never been able to replicate it myself.
I completely accept that this is happening, but does anyone have the explanation of how this could happen?
The only (crazy) thought I had is that there are some bad modules that are using a mutex to protect variable shared between the audio and gfx threads. That would of course cause problems like this, but the problems would simple go away if you stopped using Ill-behaved modules.
I don’t think that the graphics thread directly causes clicks and pops. But there’s a holistic problem with a real time audio program running on a non-realtime system, which is what VCVRack + (Windows/OSX/Linux) is.
The closer you get to saturating the CPU bandwidth, the more the system as a whole starts to have trouble with providing reliable latency, in that every task that requires a realtime response – i.e. filling an audio buffer before the driver pushes out the current buffer – can get deferred to the point it is no longer happening on or before its deadline.
That’s why if you’re running VCVRack and switch to a web browser window, Rack’s audio starts breaking up. So what you’re hearing is much less likely to be the graphics thread directly interfering with the audio thread, it’s the system as a whole not satisfying the audio thread’s realtime requirements.
What you say is true if you run the audio engine at default thread priority, but it is completely untrue if you run the audio thread at a higher (realtime) priority. That’s why we made “Thread Booster” for VCV 0.6, which worked well for a lot of people, and that’s why VCV 1.0 offers it as an option.
Also, in the specific case of just running VCV, If you have a multi-core CPU (as everyone does), the graphics will only use up one core - it doesn’t launch multiple threads just for rendering. So even at default thread priority, UI rendering can’t glitch out. Of course this is not true if you are browsing the web, as you note.
So, yes, what you say it for sure true in general, but it is not true in VCV.
Well, at first I didn’t believe it. But enough people have reported clicks and pops that were then fixed by reducing the resolution or the frame rate, etc. that at this point I believe them. Even though I can’t explain it. Hence this post. I’m pretty sure it’s “true”, but it makes no sense. Unless my theory is correct about some plugins not playing by the rules.
My guess is that this mainly happens on CPUs with integrated graphics chips or with a shared cooling system, which can get very hot and then the CPU is being clocked down to prevent overheating(?).
Just plug in here my experience.
MBPr 2013, with only 2 cores and integrated GPU.
VCV in native resolution is unusable, have to enforce low res. mode.
With lots of modules obviously CPU starting to click audio, first thing that helps is move off screen all modules in rack.
Maybe some smart dynamic fps limiting will help with this issue.
There are other factors. An app can saturate the system bus updating the GPU, which will increase latency between the audio thread and the audio driver.
Interesting theory - it does fit that facts, or at least sounds like it does. Although I’d be a little bit surprised if the gfx load would cause overheating to kick in when the (usually) much heavier CPU load for audio is the same.
Have to keep my eyes open and see if this issue is limited to laptops (or only mac laptops).
Yes, that can happen. But the load on the bus from VCV is not very big, right? A few hundred megabytes per second from drawing new frames, a tinny bit from a handful of audio channels? It’s possible, but wouldn’t be my first guess. Do you really think this is the major issue causing VCV users so much pain?
The whole point is that VCVRack works great holistically up to a certain point of CPU saturation. The audio threads can get very busy, and things go south.
I remember Andrew saying that if the graphics system can’t keep up the cpu starts taking over duties which further robs it of power. Also, the OpenGL subsystem does not just repaint dirty frames, it renders the entire graphics all the time at frame rate, so keeps the gpu quite busy at all times. I’m in no position to argue with him.
actually, on Linux it is very common, the intensive use of the graphics in some desktops produce click and pops and a lot of Xruns. not only with the rack,
whichever audio software you use
ok, but I also remember @Vortico saying that cpu usage in the UI / graphics thread will not steal cpu from the audio thread in most cases. I think your comment is more to the effect that the graphics will start to use CPU, which could contribute to overheating. Also, If you do not have the audio thread set to higher priority, and you start to run out of total CPU (all 4 cores) then audio could get pushed out. But I don’t think that’s what people with severe problems are describing. of course I too would tend to defer to @Vortico on this.
Yeah, I can’t explain it and I’m nowhere that deep into the code and frameworks. But like you say - it’s very clear that sub-par graphics performance causes sub-par audio performance, so at some level in the system there’s a connection. Whether it’s in Rack, a dependency, the OS or even hardware, I haven’t got the foggiest
Let’s reset a little here. I’m wondering why using VCV by itself (not running video capture or number crunching software or backup software at the same time) people would be reporting in large numbers that gfx load is causing their audio to break up.
As far as I know, that does not happen at all the Cubase, Pro Tools, Reaper or any other psuedo-realtime audio software. I don’t think there is anything wrong with the way VCV is designed and coded, so it makes me wonder what is different running VCV and all these other softwares? It is a mystery to me.
