PulseAudio as a sound output?

L. Rahyen 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 
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:

More information about the wine-devel mailing list