On Monday October 8 2007 10:48, Maarten Lankhorst wrote:
Damjan Jovanovic schreef:
Pulseaudio isn't "yet another sound server", it's a full-blown replacement for all other sound servers. It mixes sound better than alsa's dmix, it's a drop-in replacement for ESD, and it works even for OSS applications using oss2pulse. Some of its interesting features include per-application volume levels, RTP multicasts, the ability to embed it within an application instead of running a separate server, and a Windows port.
The reason it would be good for wine is because it (optionally) runs in realtime (SCHED_RR) priority, and is designed for low-latency playback. Even wine's latest alsa driver continuously stutters under high CPU load (play back some music with foobar2000, while searching a large PDF).
That's not the fault of our audio driver, it is because of linux doing bad things with i/o scheduling. For whatever reason as soon as a wine blocks on i/o all other threads get cpu starved. This is not a wine bug, but a linux bug.
You probably should try new linux kernel. There is high chances that it will fix these problems for you. Personally I use 2.6.23-rc8. You find that with new kernel performance is very good even under heavy load.
Maybe someone here will be interested in hearing my story with these problems (maybe you find good advice in it; besides it is about WINE related issues)... If you don't like long personal stories then you can skip rest of this message and just try 2.6.23. Just a note: when I refer to "performance" in this message I mean fairness, smoothness and efficiency of CPU sharing between processes under high average loads not wall-clock execution time.
Many years ago I switched to Linux. And everything was great but performance under heavy load was very poor. Windows performance under heavy load is much worse but this doesn't make Linux performance better (please note here that I'm talking about very old Linux versions - 2.4.x kernel series!). For example when I tried to launch game with WINE during heavy load (rendering, video encoding, etc.) game was completely unplayable; even setting nice of -20 for the game and 19 for other processes doesn't help: both game and other processes loses too much performance. After some time because Linux is open source I decided to try to fix this somehow. At that time I used 2.6.x kernel series. First I tried to adjust some parameters in the kernel scheduler, then did some other modifications - and get acceptable performance even under heavy load! In fact it was possible to play game in WINE even if I have high load and high I/O to disk. Unfortunately my modifications was just a hack. I never found enough time to make a correct fix. But my modifications was stable and worked well for me. My brother likes to play games and I like to run 3D-rendering, scientific calculations, etc. (this is exactly why I have 24 hours per day heavy load almost always so it is important to be able to run games simultaneously especially for my brother). And of course no problems with audio latency anymore... After some years I decided to try some non-standard schedulers but most of them was much worse than my hack for standard scheduler. However, scheduler from ck patch-set have some good features in it. Unfortunately performance is worse with it than with my hack for vanilla scheduler so I did some modifications to ck scheduler and get very good kernel which works even better under heavy loads - in fact, really perfectly. With this kernel I was able to run games absolutely smoothly even when I have few background processes with big CPU usage (on one-core system!). It should be clear that "more background processes you have less FPS you get" in CPU limited game; only important thing here is that CPU sharing should be fair and smooth, and should respect niceness correctly. But when I have purchased 3 GHz quad-core system with 8 GiB of RAM I (again!) found big problems with fairness of CPU sharing... Even with my kernel with modified scheduler from ck patches which works very smoothly on one-core system I have really bad performance under heavy load on SMP system - this is strange because I expected better performance with quad-core system! But no, it was bad. Instead of trying to fix this myself I decided to try experimental 2.6.23-rc3 Linux kernel with new scheduler. And now, finally, I have good performance even under heavy load on my system with standard Linux kernel! I can copy big files, run multi-threaded scientific calculations in background (with total average load of about 6-12 or more) and play 3D-games in WINE simultaneously on my quad-core system. In past I was able to get same smoothness only on one-core system with my "evil hacks" and ck patch-set as I described above (with uniprocessor system instead of 6-12 load I have tested with 2-5 load). I didn't tested yet my one-core system with new 2.6.23 kernel so I'm not sure how well it will behave with uniprocessor system but I guess it should work as expected. So as you can see trying 2.6.23 kernel is really good idea if you don't like standard scheduler in older Linux kernels (or you can wait for stable 2.6.23 release if you don't want to compile kernel yourself).
Final conclusion for this topic is simple: if you have problems with audio only under some kind of heavy CPU load this isn't fault of WINE or ALSA. And now you can try new Linux kernel, it may help to resolve these problems.
You can read about new scheduler in the 2.6.23 kernels here: http://www.linuxinsight.com/cfs-scheduler-to-appear-in-linux-kernel-2.6.23.h...