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 practice.
thanks -mike