PulseAudio as a sound output?
research at science.su
Mon Oct 8 08:20:57 CDT 2007
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
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
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:
More information about the wine-devel