I am stockpiling. These are audio books downloaded from the public library. I remove the DRMs so I can time-shift them and listen to them on my schedule. When my library card expires I won't be able to renew it since I am living in Mexico now and renewal has to be done in person.

I am building a pretty impressive collection...

tanstaafl.

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

I am pretty sure I have found the root of the problem.

After five failures night before last, in which the program started feeding all 18 threads simultaneously into the speakers even though it was supposedly muted, I noticed that every time this happened it was right at the point where one thread had finished a file and was loading up the next one. A little bit of experimenting showed that if the total job contained no more files than the total number of allowed streams, there were no failures, no corrupted files. This afternoon I experimented with a 28-file, 28-stream job (28 being the maximum number of streams that the program will allow) and it went off without a hitch.

Surprisingly, CPU usage was the same as if I were running just 15 streams -- about 37%. Memory usage was way up, holding steady about 80%.

So, it looks like the way to make this work is to run 28-file batches, and reload every hour and a quarter, rather than create a batch of 150 files and let Tunebite work its way through them. It is apparently the transition from completed file to the next file in line that is causing the problem.

tanstaafl.

Sounds like the caching of the next file is making I/O momentarily block and create stuttering. Good that you've found a solution.

Just curious but can you run DPC Latency Checker?

No reason why I couldn't... but it looks pretty complicated to run and understand. I think if this new scheme of matching the number of files to the number of streams works out, I'll just let speeping dogs lie.

tanstaafl.