On Tuesday 04 April 2006 23:29, Mike Hearn wrote:
I know I didn't offer a solution, just standard rules for multithreaded application writing. The fact that wine is a compatibility layer rather than its own application is most of your problem. Is there no way wine could have an audio thread that does nothing but the compatibility component between the running win32 application and the alsa drivers? That would use very little cpu even if the win32 app internally does funky decoding and whatever else.
I don't know. I'm not an audio guy, I just implemented the kernel side of SetThreadPriority :) Hopefully one of our DirectSound gurus will pipe up, I CCd Robert Reif who did a lot in this area.
I would be surprised if the current audio thread was using lots of CPU. Looking at wodPlayer() in dlls/winmm/wineoss/audio.c, it just sits in an infinite loop either waiting for more audio or a command. There's no polling that I can see at least, not at that level.
By infinite loop I assume you mean it is sleeping, not burning cpu... But anyway, is this a separate thread or part of a monolithic "wine"?
I guess this really depends on what you mean by "little cpu time". How little is little? Isn't relying on this mechanism very fragile - you said yourself requiring a thread to be scheduled regularly is not good practice.
I think fragile is too harsh a way to describe it. You're not after 100% realtime guarantee, just good all round audio that would basically not stutter under normal circumstances. Currently you're not even getting that. Throwing truckloads of guaranteed cpu time under starvation like scheduling capabilities at the problem is not the solution. Any well behaved low cpu using process/thread will get lowish latencies under pretty much any cpu scheduler, not just mainline 2.6.
Cheers, Con