How to increase priority of MIDI input callbacks? (thread pools)
Hi,
I'm the author of a (free) realtime MIDI software called ChordEase which makes use of the MIDI aspects of the multimedia API, specifically MIDI input callbacks. In XP and before, these callbacks originated in the kernel and therefore had realtime priority by definition, but from Vista on, they originate in thread pool threads, and have a priority of zero. This is a problem because at priority zero they can be blocked by the GUI thread, causing serious latency, and I have proved that such blocking occurs.
I have experimented with raising the callback thread priority, using either of the following methods: 1) calling SetThreadPriority within the MIDI input callback function, and then setting a flag so that it isn't done repeatedly, or 2) creating a DLL that catches thread creation via DLL_ATTACH_THREAD in DllMain, and calling SetThreadPriority there. The first method is slightly wasteful since the flag has to be tested for every MIDI input event, but it also has the advantage of only affecting the MIDI input threads, whereas the second method affects all threads in the pool regardless of what they're used for. Neither method appears to cause any harmful effects but they make me nervous. Other possible methods would include 3) using the thread pool API to raise the priority of the pool (assuming I could gain access to the pool handle somehow), or 4) permanently lowering the priority of the GUI thread, which I'm very reluctant to do because of the risk of unintended consequences.
I'm assuming the MIDI input callbacks are using threads in the default thread pool though I haven't actually proved this. Assuming that's so, are these threads private to my application, or is my application sharing them with other applications? Is there a safer way to achieve the result of increasing the priority of MIDI input callbacks? It's incredibly frustrating that MS would change the behavior of MIDI input callbacks so drastically without even telling anyone, but that's how it goes!
Best regards,
Chris Korda
http://chordease.sourceforge.net/
I'm the author of a (free) realtime MIDI software called ChordEase which makes use of the MIDI aspects of the multimedia API, specifically MIDI input callbacks. In XP and before, these callbacks originated in the kernel and therefore had realtime priority by definition, but from Vista on, they originate in thread pool threads, and have a priority of zero. This is a problem because at priority zero they can be blocked by the GUI thread, causing serious latency, and I have proved that such blocking occurs.
I have experimented with raising the callback thread priority, using either of the following methods: 1) calling SetThreadPriority within the MIDI input callback function, and then setting a flag so that it isn't done repeatedly, or 2) creating a DLL that catches thread creation via DLL_ATTACH_THREAD in DllMain, and calling SetThreadPriority there. The first method is slightly wasteful since the flag has to be tested for every MIDI input event, but it also has the advantage of only affecting the MIDI input threads, whereas the second method affects all threads in the pool regardless of what they're used for. Neither method appears to cause any harmful effects but they make me nervous. Other possible methods would include 3) using the thread pool API to raise the priority of the pool (assuming I could gain access to the pool handle somehow), or 4) permanently lowering the priority of the GUI thread, which I'm very reluctant to do because of the risk of unintended consequences.
I'm assuming the MIDI input callbacks are using threads in the default thread pool though I haven't actually proved this. Assuming that's so, are these threads private to my application, or is my application sharing them with other applications? Is there a safer way to achieve the result of increasing the priority of MIDI input callbacks? It's incredibly frustrating that MS would change the behavior of MIDI input callbacks so drastically without even telling anyone, but that's how it goes!
Best regards,
Chris Korda
http://chordease.sourceforge.net/
Topic archived. No new replies allowed.