Of course we know of one connection and that’s thermal throttling. If the CPU has to take graphics rendering duties, in a system with sub-par cooling, it contributes further to thermal throttling and therefor lower cpu performance and therefor possible bad audio performance. But I seem to recall several user accounts where thermals was not a factor.
Yes, someone mentioned thermal throttling, and that is a compelling suspect.
Maybe the way most VST’s work does not pound the GPU with a constant graphics load, like Rack does…? I don’t really know graphics frameworks, but I do remember Andrew telling that the way graphics work in Rack (and OpenGL?) every bit of graphic on the screen is constantly rendered at the framerate, even if nothing is moving (hope I didn’t misunderstand), so that’s a pretty constant GPU load, just like the constant CPU load. Maybe those two factors combined, assuming I’ve understood correctly, is what sets Rack somewhat apart.
Probably me or Nik Jevel, because it’s such a clear factor from all the reports
For sure that is a difference, but “in theory” all that extra pounding on the graphics should not be able to affect the audio, which should a) run independently on different cores, and b) delay the graphics to do audio (if real-time is on).
So the “theory” is that these situations should cause the frame rate to plummet, and the UI to possibly become unresponsive, but shouldn’t harm the audio. But clearly that isn’t the reality.
Unless thermal throttling is the factor in all cases, whether the user reported spinning fans or not. There’s no question that thermal throttling will cause acute audio hickups.
Reaper is a bit special case here as that itself does not really use the GPU in its GUI, at least on Windows. It draws everything with the CPU and the result is just blitted on the screen. They recently had to add some GPU/Metal backed support for the blit operation on macOs (because of high definition screens) and at least on my Macbook Pro 2013 model that immediately caused thermal and stability issues. (Fortunately the Metal support could be turned off…)
3rd party plugins can still use OpenGL etc in Reaper, also on Windows, though.
Very interesting. Intuitively I would have thought the opposite, but clearly this is a big area in which I am so much not an expert.
Sure, but still, GPU usage by a lower priority thread should not block the audio thread.
Sure, I would think the GPU is used exactly in order to reduce the stress on the CPU with audio applications…What would be the point otherwise? (Anyway maybe this is more complicated if the CPU and GPU are actually on the same chip or because of some other reasons…)
Maybe you’re thinking too application-centric here Bruce? Resource contention can happen at many different layers, and at lower layers, like OS subsystems (e.g. Metal) and the hardware itself, things can look different than at the application layer, even sometimes quite unintuitively. I don’t know… If I was a betting man I would venture that at least 70% of the “bad graphics causes bad audio” cases is caused by thermal CPU throttling. Whether there actually is another 30% of causes is a good question…
Usually the point of GPU is one or more of a) reduce to load on the CPU for graphics drawing b) allow richer gfx that is achievable on a CPU c) allow compatibility/easy porting of software that is already using GPU rendering.
So with an audio application is should reduce the load for the drawing part, but as I keep stating, audio software is always designed so that no matter how bogged down the graphics get the audio still plays without interruption.
I have extensive first hand experience with this issue, and can tell you that the graphics can indeed get bogged down in DAW software, but it never interrupts the audio, unless there is a bug somewhere.
Wonder if disabling Aero on windows could help any?
I think it’s worth a try
I worked on a recent synth which does all the UI rendering on the GPU. Here are some insights:
- Thermal throttling IS a problem, even without integrated graphics. In our experiments, recent mac book pros with an NVIDIA adaptor started to drop the core cpu frequency to 50% while doing constant UI updates after a short amount of time. This led to an increase of measured CPU use from 10% to 70% in hosts like Ableton (available CPU time for audio buffer update). This issue totally depends on the amount of geometry and shader updates you are doing, the driver, OS, and of course the complexity of the scene. I can’t talk about that product where it mostly depended on the amount of geometry (quite a bunch of vector GFX), but it is easy to measure.
- updating UI basically means doing buffer swaps to sync the opengl context with the driver/gfx adaptor. This is quite expensive from the realtime processing perspective when you do audio. In our case wiggling a knob could easily cost more CPU time than the audio processing. Also, event handling for some OSes and UI toolkits is mind-boggingly expensive, e.g. Qt + Apple (20% cpu use, which is IMHO not acceptable).
- in-place updates of the UI from the audio thread can pollute the cache or stall the memory bus/controller/*, even if you don’t lock for an update.
What he said
good stuff. You can tell me more, but my takeways from this is that, yes cpu heat is an issue, your second point would only affect audio it you don’t run the audio thread at a higher priority (unless there are more details not provided). The third one for sure “can happen”, but do you really think it could explain the severed degradation reported by VCV users? They report that even at pretty large audio buffer sizes the audio clicks an pops constantly. We aren’t talking about moving that much data over the bus right?
I think you are right questioning the impact of such issues. I’d guess it probably is the combination of these plus X. The only way to be sure about it is to get such a low performing machine plus the selection of modules and do profiling on it. Regarding 2): UI updates involve the kernel, so quite a bit of things can happen. But in the end, if you run out of CPU, then the priority does not matter that much. Wrt. 3) yeah, probably not much data but to analyse it, profiling/measuring is necessary. The software and hardware stacks are so complex that there is no other way to know.
There is another thing that I forgot to mention before:
OpenGL is generally an issue in multi-window contexts (e.g. VST + hosts), mostly due to issues with drivers. Low end intel integrated chipsets are the worst, that’s also why they are blacklisted in most wide-ranging applications (chrome, firefox, Qt apps, …). The workaround there is to use ANGLE on Windows machines which kind of re-directs the OpenGL API to DirectX. I’ve heard but not investigated that recent changes in OSX worsened the OpenGL performance/issues.
Thanks for your real insights here, fascinating stuff that I think confirms quite a bit of our speculations here.
Unfortunately I wouldn’t be surprised. I vaguely remember articles about Apple going all in on Metal and letting OpenGL languish in MacOS. It seems that the major OS vendors are into major walled-garden mode with regard to their graphics stacks. From a casual distance it sounds to me like Vulcan is the new low-level API for GPU’s that’s being invested in across the board, and I’m wondering out loud now, whether the future of high performance, cross platform graphics, will be (is?) DirectX/Metal/GTK/QT bindings/wrappers for Vulcan. Wonder if you could shed any light on that…?
The promoters of Vulkan certainly wanted to come up with a cross-platform solution that appealed to everyone, but politics got in the way. In the end, Apple is only developing Metal, and is letting OpenGL drivers rot. Windows makes sure the best and greatest is DirectX. Linux is sticking mostly with OpenGL. Only Android has embraced Vulkan.