It's already at HIGH_PRIORITY_CLASS, which I think is high enough; the only remaining level above that is REALTIME_PRIORITY_CLASS, which would probably be fairly lethal, as it preempts virtually all system activity, including disk flushes, and will of course freeze the screen. Even CTRL_ALT_DEL may not work. It is essential for me that I can rely on this means of killing an unresponsive program.
At present, PD is mostly single-tasking, not least because the audio is handled by polling the drivers (rather than by using callbacks or waiting on events). By adding a Sleep(1) call inside the polling (RESYNC) loops, control can be returned to the NT scheduler, so that the user interface can be updated. It also makes the polling loop less affected by different processor peeds.
I am getting fairly useful performance from PD this way, and would not like the GUI to be frozen out.
Other speed-up solutions would require more designed multi-threading, and ultimately placing the audio engine at Kernel level as a Device, in some way. TK itself is pretty slow - of course, a fully native-Windows GUI implementation would give a significant speed-up. Or port the whole thing to the Creamware SCOPE system!
Richard Dobson
Guenter Geiger wrote:
Hi there !
Does anyone know how I can give higher priority to pd under Windows NT ?
Thanks in advance
Guenter