2 ms·

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 rel

by 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

by esaym 10y ago

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