One thing that did work beyond my expectations was increasing the priority. As an experiment, I set the priority to "Realtime" and ran 44% more simultaneous audio streams than I had ever successfully run before (increased from 18 streams to 26) and had a flawless conversion. (This was with virus scanning temporarily disabled.) Now perhaps I was just lucky and no other processes started up during the run, but this is definitely something I will try again.
Stop me if I'm sounding a bit like a certain other BBSer in making rash assumptions about how bits of closed-source software work, but now you mention it, that does make perfect sense. If WMP thinks it's feeding a real sound card, it will probably itself be running at an elevated priority, perhaps even "Realtime" priority. So if Tunebite's transcoder is running at a lower priority, it will get starved out completely in the case of too many WMPs, its buffers will overflow and the audio will go glitchy. However, if Tunebite is also running at "Realtime" priority, it will still get scheduled a bit even if there are lots of runnable WMPs, the two will share the CPU nicely like good little children, and there'll be no glitching even if potential CPU use is over 100% (i.e. if there's always a waiting list for CPU).
Peter
Previous Topic
Index
