mike at plan99.net
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
More information about the wine-devel