bug 15559 repairs the pulseaudio patch the 1.1.10 broke. Yes development tree these kinds of breaks are to be expected. Patches are in the development tree because they need testing. Difference between pulseaudio and dmix is fairly major. Adding per application volume controls ands a extra level of mixing and altering. dmix there is the application sound output buffers and output buffer to sound card and quite simple transformations between most complex dmix alteration is a bit width alteration. Pulseaudio there is application sound output buffers these are then mixed to a intermittent buffer then applications volume control alteration and other alterations applied then finally passed on to card for output. >From a cpu usage point of view Pulseaudio is at least 4 times heavier than dmix. That is before you enable stuff like 6 channel virtual sound card being output on 2 channel. You are paying a price for it. Yes if your sound card has a onboard mixer alsa supports hardware acceleration of audio mixing there will be almost no cpu load at all. Soft disabling pulseaudio also nastly fails on non hardware mixing cards. No matter how much I have asked the developer of pulseaudio to enable auto starting of dmix or a warning that no mixing is provided he has flatly refused to do either. So effectively left with a crippled audio setup if your card does not have hardware audio mixing. Yes Ubuntu has made it extremely hard to use the lightest audio setup. http://lwn.net/Articles/268937/ << Hopefully Ubuntu build with cgroup in kernel. Thinking in newer Linux kernel you have to go out of your way to disable it. When building kernel from source graphical configuration don't even give you the option to disable it. Since its classed as kinda key feature. Cgroups can do a lot more than just memory control they can also control what devices a application can access, network access what percentage and ammount of cpu time applications get. Really useful tool for misbehaving programs. Thing most people are not aware is that all processes in kernels with cgroups enabled are always running in a cgroup. The default cgroup. Any process that a application starts remains in the cgroup the application that started it is in unless assigned else where. Becareful with them very powerful tool. Highly useful. Controlling cgroups is one time where running as root/admin is kinda required. Knowing the process id of a normal users shell allows that to be transfered into cgroup to run wine. echo $$ will tell you the PID of current bash.
