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 differences?
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