Mike Hearn mike at
Tue Apr 4 07:42:00 CDT 2006

> What strikes me is that people are very happy to think that the kernel is 
> going to fix this problem. I have to tell you there will be no more 
> infrastructure put into the kernel anytime soon to help you here. 

I'm confused about this point. You say the kernel won't be changing 
anytime soon - does this mean you've given up on getting SCHED_ISO into 
the mainline kernels? Can we _really_ not expect any support from the 
kernel people here?

> I do not believe you are going to need real time scheduling to get audio to 
> work properly. This really is overkill in my opinion. 

OK. We'd love some alternative, if only because Alexandre seems dead set 
against anything that requires root access, even if that includes not 
running Wine itself as root.

> Audio playback and decoding should not really use much cpu. 

I'm not even sure we can control that. Some games seem to set up their 
own mixing threads and such (looking at the SDL Win32 code it calls 
SetThreadPriority itself).

Also this issue is wider than just audio, though this is where it hurts 
us the most. I guess there are other cases where a Windows program needs 
to raise thread priorities. Isn't Photoshop susceptible to scheduling 

> Lastly, and this is not a comment about wine but all programming in general, 
> multithreading cannot be left up to chance.

What do you suggest, that we find some way to make audio threads in Wine 
block/swap with more intensive threads? I'm having a hard time imagining 
how this would work ... we don't control what the other threads are 
doing, so ... hmmmm. I don't see any way to guarantee that every other 
thread will block on the audio thread often enough that the buffers 
never run down.

thanks -mike

More information about the wine-devel mailing list