Implement THREAD_PRIORITY_TIME_CRITICAL

[Con Kolivas]

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