On Saturday, 17 September 2016 at 15:41:24 UTC, John Colvin wrote:
On Saturday, 17 September 2016 at 09:26:50 UTC, Guillaume
In this post, I describe the software renderer available in
Isn't that rather a lot of work to be doing? In my experience
with audio work, reducing any and all cpu usage - even in low
priority threads - was useful in getting stability at low
latencies. Even when not considering latency, I was often
limited by cpu throughput when getting towards the end of a mix
(of course can render/freeze things, but that's not always
possible or convenient).
Some customers use it on every track.
A closed UI does not consume CPU.
Second, the data going from audio thread to UI uses a
double-lockfree queue so the GUI can be arbitrarily slow without
impact on the audio.
What happen on overload is that the UI will receive less repaint
message from the OS.