3 ms·

I am annoyed by PulseAudio because I don't know how it relates to ALSA. Every time I made an audio related project on a Raspberry Pi, be it to stream the incom

I am annoyed by PulseAudio because I don't know how it relates to ALSA. Every time I made an audio related project on a Raspberry Pi, be it to stream the incoming signal of a USB-mic via ffmpeg/avconv to a server, try to get a ReSpeaker 2-Mics Pi HAT working, stream a MP3 radio stream to a speaker, anything related to sound, I'm always confronted with ALSA as if it were the default audio system on Linux. But then something doesn't work, and I get referred to PulseAudio, and then I have these two audio systems somehow working together, and I don't know why, but somehow it works, and I'm left clueless about what is going on down there in the OS with all this sound thing. The .asoundrc file, which is from ALSA, but apparently is used to set up some things in PulseAudio, or not, all this stuff has left me confused as hell. If PulseAudio is so much better, then why is ALSA the default? Is it even the same, like a replacement? At least this rant has pushed me now to seek explanatory YouTube videos on this matter, but I think that I'm not the only one who is confronted with this confusion.

AndrewDavis 6y ago
Pulseaudio is a middleman between applications and ALSA. There is no Pulseaudio without ALSA. EDIT: Forgot OSS can also be the back end as an alternative to ALSA I highly suggest reading the Arch Wiki page on Pulseaudio. https://wiki.archlinux.org/index.php/PulseAudio https://wiki.archlinux.org/index.php/PulseAudio
catdog 6y ago
> I'm always confronted with ALSA as if it were the default audio system on Linux. Because it is as far as the kernel drivers for audio devices are concerned. You have to distinguish between that and the userspace part called libalsa. > If PulseAudio is so much better, then why is ALSA the default? Is it even the same, like a replacement? Pulseaudio can be seen as a replacement for libalsa while it still talks to the ALSA kernel drivers in usual setups. The fundamental conceptual difference is that pulseaudio is a sound server and libalsa is a library which is directly included into a program. > The .asoundrc file, which is from ALSA, but apparently is used to set up some things in PulseAudio, or not, all this stuff has left me confused as hell. This is actually the configuration file for libalsa. The pulseaudio stuff in there is configuration for a compatibility plugin shipped with pulseaudio which presents an audio device to the application using libalsa redirecting everything to pulseaudio instead of directly talking to the Kernel. That way applications without native pulseaudio support can still be used without issues while pulseaudio is running.

AndrewDavis 6y ago

Pulseaudio is a middleman between applications and ALSA. There is no Pulseaudio without ALSA. EDIT: Forgot OSS can also be the back end as an alternative to ALSA I highly suggest reading the Arch Wiki page on Pulseaudio. https://wiki.archlinux.org/index.php/PulseAudio https://wiki.archlinux.org/index.php/PulseAudio

catdog 6y ago

> I'm always confronted with ALSA as if it were the default audio system on Linux. Because it is as far as the kernel drivers for audio devices are concerned. You have to distinguish between that and the userspace part called libalsa. > If PulseAudio is so much better, then why is ALSA the default? Is it even the same, like a replacement? Pulseaudio can be seen as a replacement for libalsa while it still talks to the ALSA kernel drivers in usual setups. The fundamental conceptual difference is that pulseaudio is a sound server and libalsa is a library which is directly included into a program. > The .asoundrc file, which is from ALSA, but apparently is used to set up some things in PulseAudio, or not, all this stuff has left me confused as hell. This is actually the configuration file for libalsa. The pulseaudio stuff in there is configuration for a compatibility plugin shipped with pulseaudio which presents an audio device to the application using libalsa redirecting everything to pulseaudio instead of directly talking to the Kernel. That way applications without native pulseaudio support can still be used without issues while pulseaudio is running.