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