Quote:
Originally Posted by Klangfarben
assigning a dedicated core or cores to the GUI...
|
I don't suppose this will help in a "CPU busy" situation, as you describe. In a DAW by default CPU threads assigned to audio are higher priority, meaning that the GUI will lag, if all CPU power is needed for audio, but the GUI will automatically get the remaining CPU cycles as soon as it's possible to calculate the audio without dropouts. Audio only is allowed to wait for as long as the buffer setting says. This is not an amount of time the smoothness of the GUI will noticeably benefit from.
Hence in such a "busy" situation, dedicating a core to the GUI
will result in degrading audio. This might be what you want in certain situations, but it's bad as a default behavior.
In a "non busy" (audio not demanding or stopped) in fact only one core will do GIU work. Here in fact using multiple cores (i.e. OS threads) might help. But doing so is a lot of work, as communicating with the widget set tools of the OS with multiple threads is non-standard and rather complicated and error-prone. (I in fact did such stuff some years ago.).
Offloading some visual work to the GPU (handling the GUI like a game programmer would, e.g by using a framework like OpenGL)
might speed up the GUI without hampering audio. But that needs a complete overhaul of a program initially done by a different GUI tool set (widgets). I in fact once helped doing this for a computer graphics program
.
-Michael