On Tue, 4 Apr 2006 01:47 am, Andreas Mohr wrote:
Hi,
[sneaked in another CC, JFYI ;]
Oh hi! This is the first time this thread has been brought to my attention.
On Mon, Apr 03, 2006 at 04:29:43PM +0100, Mike Hearn wrote:
And even then, SCHED_ISO is a long way off and may never be merged. Waiting for it wouldn't be helping users today, which is a bad thing IMHO.
I don't think SCHED_ISO is necessarily a long way off. Recently there has been more activity in getting scheduler improvements into mainline, so some form of SCHED_ISO class might appear soon.
I've had a whole read of this thread online now that I've found it and there are a number of things that I should mention since people seem quite happy to talk around my code :)
SCHED_ISO is a stable, mostly realtime solution for normal users. The one scenario that SCHED_FIFO was required _over_ the capabilities of SCHED_ISO is only professional audio sampling/capture work where one process may require almost 100% cpu for bursts of many seconds. Therefore for audio playback, SCHED_ISO is more than qualified.
While I'm pleased that SCHED_ISO fixes the problem for many people on this thread, I have to tell you that it is _not_ the solution to your problem for a number of reasons. My motivation for creating this scheduling class was for transparent realtime performance to be attainable for an ordinary desktop user without their knowledge or previous setup. The reason is that the current system for giving realtime privileges to ordinary users is complicated and not set up properly by hardly any distributions. This is the real time rlimits capabilites which is already in the kernel.
I'm disappointed yet again that there is no simple way for something as low cpu using as audio on wine cannot get low enough latency for ordinary playback without realtime scheduling. I've mentioned this on the mailing list before. The fact that the cpu scheduler is going to completely reorder processes in the order it sees fit, based mostly on cpu usage and wakeups means that unless there is some form of blocking between audio and the heavy cpu using game, there will be no guarantee that audio will be scheduled in preference to the game. This is obviously what you're seeing.
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. Since I have the displeasure of having to reiterate this to you I should probably offer some useful suggestions if I could think of some...
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. However if you really want to go down this path you need to use the kernel infrastructure that is already in place. The realtime rlimits is there and works. Getting modern distributions to have it set up by default properly is the first challenge. I have not investigated to see who has done this, but if they are not then pinging the distribution maintainers or even helping them set it up is the thing to do here. Providing walk-throughs on setting it up (until the distros catch up) and using the system from within wine seems appropriate.
Audio playback and decoding should not really use much cpu. Processes that do not use much cpu are given preferential low latency in the kernel without changing scheduling class. The way to ensure that audio playback therefore always "wins" over cpu intensive games is to have a separate audio playback thread that uses as _little cpu_ as possible. This means it should do just the audio playback and do nothing else. Last time I checked the alsa code it does queueing/blocking without needing any extra polling. The practice, for example, of xmms(1) of checking to see if there's room in the queue every 10ms is ancient and the wrong way to code audio.
Lastly, and this is not a comment about wine but all programming in general, multithreading cannot be left up to chance. More than ever with multiple cpu cores, logical cores, threads and an out-of-queued-order cpu scheduler, threads _must_ block on each other as much as possible. It cannot be left up to chance if they depend on each other. Use of sched_yield for example which just gives up the cpu for a random duration in the hope another thread gets scheduled meantime is basically wrong for anything but realtime tasks of the same priority. It has no place in modern code. All that will end up happening is processes will wake up and use cpu (spinning) for nothing decreasing throughput, and latencies will blow out. Again I'm not saying wine does this, but feel obliged to say this whenever the cpu scheduler is blamed for wrong "ordering" of tasks.
Hope this helps
Cheers, Con