Mike Hearn mike at
Tue Apr 4 08:29:42 CDT 2006

> 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.

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 

thanks -mike

More information about the wine-devel mailing list