4 ms·

> I couldn't stand the PA process hanging around in the background eating 20% of my cpu...especially on laptops. That's likely a artifact of you needing to con

> I couldn't stand the PA process hanging around in the background eating 20% of my cpu...especially on laptops. 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.

esaym 10y ago
This is good info but here is the thing. On my minimum base install of debian stable with only a couple of the kde packages, I don't actually have any sound related packages installed: 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:~# There is no alsa or asound stuff in /etc or anywhere. So to clean up my "alsa hacks", I'm not sure where I'd even start because I don't see anything anywhere. What ever is working, is working just fine with what ever defaults there are. From the user perspective, this is great, everything works with no overhead (I guess). But I can see from the developer perspective, how it would be easy to "code" just against PA, and out side of that I'm not sure what you'd code against since I don't even see how my current set up is even producing sound at all. The only runtime related thing I can find for alsa is /proc/asound/ 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.
- esaym 10y ago
  So I did some research. I noticed some people speaking of DMIX in alsa for doing software mixing. One can install some plugin packages to enable a configurable resampler (libasound2-plugins on debian). You can then set /etc/asound.conf with some thing like: defaults.pcm.rate_converter "samplerate" But I couldn't really tell a difference in cpu usage when audacious was playing anything. I figured since "ALSA" was also synonymous with "kernel driver" that I would only see increased cpu usage in kernel land, which I wasn't. After getting a bite to eat and thinking about the problem, even though I don't really have a full understanding of the ALSA architecture, it dawned on me that I might be thinking about it wrong. The ALSA api is userland, so perhaps when sound is passed from an application to the alsa library, the CPU cycles would then happen within the application generating sound? I tried my test again, sure enough audacious used 10% cpu with speexrate versus 30% with samplerate_best. So I'd been complaining about CPU usage of pulseaudio daemon when it was actually offloading the load from the application (and not adding to it) 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 https://wiki.archlinux.org/index.php/PulseAudio [1]https://git.archlinux.org/svntogit/packages.git/tree/trunk/asound.conf?h=packages/pulseaudio-alsa https://git.archlinux.org/svntogit/packages.git/tree/trunk/a... [2]https://hydrogenaud.io/index.php/topic,9772.0.html https://hydrogenaud.io/index.php/topic,9772.0.html

esaym 10y ago

This is good info but here is the thing. On my minimum base install of debian stable with only a couple of the kde packages, I don't actually have any sound related packages installed: 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:~# There is no alsa or asound stuff in /etc or anywhere. So to clean up my "alsa hacks", I'm not sure where I'd even start because I don't see anything anywhere. What ever is working, is working just fine with what ever defaults there are. From the user perspective, this is great, everything works with no overhead (I guess). But I can see from the developer perspective, how it would be easy to "code" just against PA, and out side of that I'm not sure what you'd code against since I don't even see how my current set up is even producing sound at all. The only runtime related thing I can find for alsa is /proc/asound/ 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.

esaym 10y ago
So I did some research. I noticed some people speaking of DMIX in alsa for doing software mixing. One can install some plugin packages to enable a configurable resampler (libasound2-plugins on debian). You can then set /etc/asound.conf with some thing like: defaults.pcm.rate_converter "samplerate" But I couldn't really tell a difference in cpu usage when audacious was playing anything. I figured since "ALSA" was also synonymous with "kernel driver" that I would only see increased cpu usage in kernel land, which I wasn't. After getting a bite to eat and thinking about the problem, even though I don't really have a full understanding of the ALSA architecture, it dawned on me that I might be thinking about it wrong. The ALSA api is userland, so perhaps when sound is passed from an application to the alsa library, the CPU cycles would then happen within the application generating sound? I tried my test again, sure enough audacious used 10% cpu with speexrate versus 30% with samplerate_best. So I'd been complaining about CPU usage of pulseaudio daemon when it was actually offloading the load from the application (and not adding to it) 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 https://wiki.archlinux.org/index.php/PulseAudio [1]https://git.archlinux.org/svntogit/packages.git/tree/trunk/asound.conf?h=packages/pulseaudio-alsa https://git.archlinux.org/svntogit/packages.git/tree/trunk/a... [2]https://hydrogenaud.io/index.php/topic,9772.0.html https://hydrogenaud.io/index.php/topic,9772.0.html