I'm still happy with them as a browser. But not sure now if they force PA on me. I've tired to use/install it (PA) before, but I couldn't stand the PA process hanging around in the background eating 20% of my cpu...especially on laptops.
1) copy the default config to ~/.pulseaudio
2) edit out the device autodetection and add in loading just the jack module
3) if you have more than a single device, either add it to the pulseaudio config (i.e. bluetooth comm device for use with skype) or use alsa_in and alsa_out to connect an additional alsa device to jack, then add the device to the pulse config as an additional source/sink pair
4) keep the default alsa device pointing to an alsa-pulse bridge. Yes, this sounds crazy when you can just layer alsa on jack rather than on pulse->jack, but this way you get the per-application volume controls, which are one of the few really good features of pulse. If you don't care for per-application volume controls, just layer alsa on top of jack directly.
With this setup, pulse acts as a simple bridge to jack and jack does a much better job of controlling your sound card, remixing, etc. I have a hunch that the absolute single best sound setup on linux would involve patching jack to basically act like pulse w.r.t automatic device management and then add the native pulse protocol to it.
You were right about that, I tested it in another comment on here. I thought that resampling would happen within a kernel driver or something. But no, apparently when an app uses the alsa library, the functions that resample will happen within the app generating the sound (and thus in userland).
That's likely a artifact of you needing to configure these things yourself and not doing a very good job.
This is where distros that force users to configure basic features like audio do a real disservice. In 2016 nobody should be configuring anything to do with audio unless they are doing audio production. If a problem comes up the only thing that should be done is to file a bug so it can be fixed. Working around bugs by trying to configure something is nasty business, but unfortunately when distributions don't do the work it forces users to do it.
Going from a system that is configured to use Alsa and then trying to go to Pulseaudio is a PITA and is surprisingly difficult to get right.
Here are the basic steps:
* First you need to undo the damage caused by the usage of things like 'alsamixer'. Alsamixer does a very poor job exposing the low-level mixer controls on your hardware. A lot of the controls are only partially functional and turn on or enable some configurations in spooky ways that can't be undone. Bad configuration settings caused by things like alsamixer cause endless headaches because it jacks up Pulseaudio's ability to configure the hardware correctly sometimes.
To prevent current settings from carrying over to the next reboot you need to locate your 'asound.state' file were the alsa service stores your configurations between reboots. Delete that and symbolically link it to /dev/null, reboot, and then turn it back to a regular file.
* Find all your Alsa 'hacks' and get rid of them. Your .asoundrc files and the like. You definitely do not want to be doing things like setting bitrates or buffers or the like using Alsa configuration files. Get rid of dmix and any other alsa plugins you have configured. They are counter productive. You can do that by configuring PulseAudio if you really want to.
* Make sure that Pulseaudio is using hardware device directly and not going through something like 'dmix'.
* make sure that your init system is doing things correctly and that no sound gets kicked off before Pulseaudio latches to the hardware. Modern hardware has no hardware mixing features because they increase cost and lower audio quality.
* Make sure your software is configured to use Pulseaudio directly whenever possible. This can be very difficult, unfortunately, because there are a huge numbers of audio libraries and whatnot that applications use and they are all configured differently.
If CPU usage is still a issue after you have it setup initially you can control the type of resampling algorithm you use.
Alsa with DMIX uses as much CPU as Pulseaudio on 'Trivial' resampling method. A lot of the difference in cpu usage is psychological. When the default configuration of Alsa burns up cpu with resampling it doesn't show up in things like 'top'.
On a laptop, with Pulseaudio configured correctly, you should see a slight reduction in energy use.
root@t61:~# dpkg --get-selections |grep -i "pulse\|alsa\|sound"
gstreamer0.10-alsa:amd64 install
gstreamer1.0-pulseaudio:amd64 install
libasound2:amd64 install
libasound2-data install
libclalsadrv2 install
libpulse-mainloop-glib0:amd64 install
libpulse0:amd64 install
libsdl-sound1.2:amd64 install
libsoundtouch0:amd64 install
libzita-alsa-pcmi0:amd64 install
root@t61:~#
You say alsa uses more CPU than PA? But how can I verify that? Even if alsa runs entirely in kernel land, it would show up in regular top. But comparing the default alsa setup with a default PA setup, top shows very differently.
defaults.pcm.rate_converter "samplerate"
I went ahead and installed pulseaudio, (there was some good info here[0]), I set up ALSA to by default use PA through /etc/asound.conf[1]
Rebooted and everything seems to work fine so far (though I haven't tried suspending on the laptop which seems to be trouble for some). Ironically when I play stuff on soundcloud through firefox, the CPU usage for one of the FF process would always hang around 50%, now it is hovering between 20-30%, so perhaps it even lowered that usage as well. audacious uses about 6-7% CPU now as well.
The default resampling of pulseaudio works good too. You can try playing this dial tone file that has a hidden 19khz tone in it[2]. If the resampling is not done good enough, you'll end up with an audible interference pattern (it would show up on ALSA, but not with pulseaudio now)
[0] https://wiki.archlinux.org/index.php/PulseAudio
[1]https://git.archlinux.org/svntogit/packages.git/tree/trunk/a...
Sounds like a misconfiguration if anything.
For a typical user - PulseAudio "just works" and there's no more to it than that. It does make large improvements over just plain ALSA, and as far as I know, is included in all the major Linux distros... so many folks use it and never even know nor think about it.
Nope. Sleep mode, no matter what distro you use, causes issues from 2008 until today [0][1][2]...[n]
[0] https://wiki.archlinux.org/index.php/PulseAudio/Troubleshoot...
[1] http://askubuntu.com/questions/762816/ubuntu-16-04-changes-s...
I've tried to figure out what exactly the linux sound system looks like under the hood, but I really can't. And then I come across pages like this: http://askubuntu.com/questions/581128/what-is-the-relation-b... that flat out state PA just sits on top of ALSA. So in my mind, if everything just works with out PA, why install it?
Yes, PA sits on top of ALSA. But PA does have other features, for example sending audio over the network, which is something that I have used on systems that don't have soundcards (e.g. Windows Subsystem for Linux) and for routing all my audio through my OpenWRT router which is connected to my high quality stereo (which allows all computers in my room to output audio to speakers without any cables). Also things like grabbing audio out from one app and recording to audacity is easy with PA.
That being said, I'm the type of person that prefers minimal systems, in which case I usually stick to LXDE sans-pulse, and if I do need advanced audio processing, then I go with Jack.