Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Linux audio stack demystified (and more)

blog.rtrace.io

Post reply on HN
Print view View original

21–30 of 136 posts

Re: The Linux audio stack demystified (and more)

#21

Post by runiq »

shmerl wrote: post #3

> ALSA is the core layer of the Linux audio stack. It provides low-level audio hardware control, including drivers for sound cards and basic audio functionality. > ... > Ulike PuleAudio and JACK, PipeWire does not require ALSA on a system, in fact if ALSA is installed the output of ALSA is very likely pushed through PipeWire I don't get this part. If ALSA represents the kernel level hardware drivers for audio, how do…

That part is simply wrong. Pipewire uses Alsa to drive the soundcard. Alsa is a hard requirement.

Re: The Linux audio stack demystified (and more)

#22

Post by daghamm »

g15jv2dp wrote: post #12
shmerl wrote: post #6

Earlier quoted context omitted.

Pipewire is a major development that's especially important for Wayland desktop. It was hard to miss unless you haven't used Linux in a long time.

I've been a WSL user for years now. Way less effort.

Until vmmem starts using 100% of your CPU and you need to kill the WSL service to get your computer back (without the unsaved work of course).

But yeah WSL is just too easy. Specially with native vscode support it has become a favourite for many developers

Re: The Linux audio stack demystified (and more)

#24

Post by kmarc »

I hear many complaining (even here) about "the mess" of linux audio.

First, in the article, [1] shows in one single diagram where the complexity is coming from; the audio system has to handle a good deal of different hardware on many different systems and also provide extra functionality for multiplexing, network features, wireless headsets and their codecs, etc. All this: open source.

Second: linux is the only platform where everything works right now flawlessly for me: My Bose joins without any problems, switches to headset mode during zoom calls, switches back to high definition audio otherwise. I can select a different sink, even networked, whenever I want the output to appear on a different networked device. MacOS sometimes needs a reboot so that the bluetooth subsystem works, what the hell.

And all this worked with PulseAudio, and now works with Pipewire, which is an even higher quality iteration of PA.

I don't complain. I wish MacOS/Windows had such a versatile, configurable, but sanely-working-out-of-the-box audio system as an off-the-shelf Fedora, or even freaking Arch linux has.

HTH

[1]: https://blog.rtrace.io/images/linux-audio-stack-demystified/...

Re: The Linux audio stack demystified (and more)

#25

Post by erremerre »

bigstrat2003 wrote: post #10
g15jv2dp wrote: post #5

I now have flashbacks to when I tried to get sound working on my Gentoo install 15 years ago. It seems that now everything has changed (wtf is pipewire) and still requires arcane knowledge to get everything working smoothly...

To be honest, I wouldn't say it requires arcane knowledge these days. When setting up both Arch and Gentoo, I did a bit of research, determined that Pipewire was probably the best for me (because it seems to be largely a superset of the other options), and installed it following the wiki instructions. That's it. I haven't had to configure things in any sort of detail, it just worked smoothly the first time without an…

Let me guess, you don't have a Realtek controller for audio.

Re: The Linux audio stack demystified (and more)

#26

Post by sihox »

It's pretty nice article but for me - just for introductory purposes. It shows how sound and digital audio works and what basic libraries and tools we have in linux to deal with sound. But I'm still stupid when it comes to details and user interface tools. The article(s) I really love to see is, on one hand, more technically detail-specific and, on the other hand, broadly defining options I can have as an end user. I mean - from basic tools (CLI, GUI) that are available for simple purposes like volume control, stream selection, etc. to pro-audio, complex scenarios. For me it's too many tools and options I can use in linux for audio and this is the reason for being lost sometime. Of course for daily use I have pipewire with pulse, alsa and jack "plugins" which gives me seamless cooperation with lots of apps and controls but maybe I can get rid of some module or app...

Re: The Linux audio stack demystified (and more)

#27

Post by vladvasiliu »

erremerre wrote: post #25
bigstrat2003 wrote: post #10

Earlier quoted context omitted.

To be honest, I wouldn't say it requires arcane knowledge these days. When setting up both Arch and Gentoo, I did a bit of research, determined that Pipewire was probably the best for me (because it seems to be largely a superset of the other options), and installed it following the wiki instructions. That's it. I haven't had to configure things in any sort of detail, it just worked smoothly the first time without an…

Let me guess, you don't have a Realtek controller for audio.

I do have one, whatever HP figured was good enough for their "high-end" elitebooks. Worked perfectly on Arch without any fiddling. Even the mute leds on the keyboard work as expected.

Re: The Linux audio stack demystified (and more)

#28

Post by Cloudef »

Pipewire has pretty much unified the userland linux audio stack (+ supports video as well as bonus). Kernel side it has always been alsa. There's TinyAlsa so you don't have to use libasound to interface with the kernel alsa. (userland alsa is quite PITA)

Re: The Linux audio stack demystified (and more)

#29

Post by Cloudef »

oleg_antonyan wrote: post #20
g15jv2dp wrote: post #5

I now have flashbacks to when I tried to get sound working on my Gentoo install 15 years ago. It seems that now everything has changed (wtf is pipewire) and still requires arcane knowledge to get everything working smoothly...

PipeWire is drop-in replacement for pshshaudio with additional features (while preserving pshsh part sometimes). Only difference is 15 years ago half of the problems with sound were fixed by uninstalling pulseaudio as it was in early stages full of bugs but still pushed to many distros similar to systemd. Today's pipewire is as easy as uninstalling pulseaudio, installing pipewire, and most of the times it will contin…

To be fair. Pulseaudio in early days exposed tons of audio driver bugs that were since then fixed. Bluetooth audio was barely working back then. Now bluetooth works so well that it makes other operating systems look bad.

Re: The Linux audio stack demystified (and more)

#30

Post by bux93 »

kmarc wrote: post #24

I hear many complaining (even here) about "the mess" of linux audio. First, in the article, [1] shows in one single diagram where the complexity is coming from; the audio system has to handle a good deal of different hardware on many different systems and also provide extra functionality for multiplexing, network features, wireless headsets and their codecs, etc. All this: open source. Second: linux is the only platf…

I'm sure the windows audio stack is many times more complex, and it's pretty opaque.

OEMs also love to include all kinds of audio related bloatware, which makes getting audio hardware to work reliably(!) quite challenging. The HP laptop I'm typing this on has an "Intel microphone array" (just 2 mics) which has it's own intel drivers, but there's also some HP control panel, realtek and 'sound research' branded stuff, Fortemedia SAMsoft effects(?), Intel smart sound...

If I'm recording seriously, I usually just go to the device manager (devmgmt.msc) and disable as much as I can and enable devices in a trial-and-error way to see what the minimum is to get audio to work again. Otherwise, all kinds of 'enhancements' end up in the audio path.

Post reply on HN