THREAD_PRIORITY_TIME_CRITICAL with NAN
sonoro1234 opened this issue · comments
for win32 THREAD_PRIORITY_TIME_CRITICAL is too much: when there is a NAN in supercollider CPU eaten by supernova is 98% so user is not able to do anything like a system hang. THREAD_PRIORITY_HIGHEST could be tested
i see your point ... though it is probably better to isolate the ugen which is causing these problems instead of reducing the priority of the audio threads. otoh: supernova contains some code for preventing live-locks: the process will terminate, if the main audio thread stalls for a few seconds. though of course this fails if a ugen in the main thread live-locks.
maybe the better solution is to configure supernova at startup time to use high or highest priority?
Yes but it is also more work and THREAD_PRIORITY_HIGHEST is already alot!!!
There is also another start option (-Z) about audio latency that had to be implemented (current behaviour is using max default latency from device)
and another option making to crash (portaudio at least) is to call it with -H "" (no device)
----- Original Message -----
From: Tim Blechmann
To: timblechmann/nova-tt
Cc: Victor Bombi
Sent: Saturday, June 07, 2014 11:11 AM
Subject: Re: [nova-tt] THREAD_PRIORITY_TIME_CRITICAL with NAN (#1)
i see your point ... though it is probably better to isolate the ugen which is causing these problems instead of reducing the priority of the audio threads. otoh: supernova contains some code for preventing live-locks: the process will terminate, if the main audio thread stalls for a few seconds. though of course this fails if a ugen in the main thread live-locks.
maybe the better solution is to configure supernova at startup time to use high or highest priority?
—
Reply to this email directly or view it on GitHub.