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

31–40 of 136 posts

Re: The Linux audio stack demystified (and more)

#31

Post by Cloudef »

thriftwy wrote: post #2

I remember there was oss and alsa. Then on top of that you had esd or artsd, with incompatible APIs and userland delays. Then at some point they were replaced with pulseaudio. I've just noticed now that pulseaudio is also replaced with pipewire in latest Ubuntu. That does not instill confidence in that they have any idea what they are doing. I remember that as far as on 2012 some Linux game ports from Steam (before P…

Pipewire unifies all the apis, and is fully backward compatible. It has own API too, but you don't have to use it. You can write app using any of the apis, alsa, pulse, jack, and pipewire can work with it. You only need pipewire api if you need more control or pipe through video as well.

JACK is very flexible approach to audio (think of unix pipes but audio) and this is what pipewire is inspired by, but targets the general desktop use and not just audio production as JACK does.

Generally pipewire stays out of the way and works as pulseaudio replacement, but with the pipelines you can do a lot as a power user.

Personally I think pipewire is one of the best things that has happened to linux, and since it shims all the previous audio apis instead of trying to tape the existing solutions into the package, it actually removes bloat from your system and you don't have to write weird libasound config files anymore.

Re: The Linux audio stack demystified (and more)

#32

Post by hparadiz »

bux93 wrote: post #30
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,…

If Windows could do what Linux can out of the box VoiceMeter would not exist.

Re: The Linux audio stack demystified (and more)

#33

Post by woolion »

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 wholeheartedly agree, but the frustrations are quite understandable. If you want to do something somewhat advanced and you have to care about Jack, Alsa, and then the Pulse or Pipewire layers, it's quite overwhelming (why would you have to know the Linux audio history to work with it).

PulseAudio was quite buggy when it was considered ready for general public by Ubuntu. I kept using some scripts to do what it could theoretically do for 2/3 years, and then it didn't have any quirks anymore.

Now that it is replaced by the pipewire stack, audio bugs are back. For instance, on a laptop if system audio is set to 'output' instead of duplex, switching between speakers and headphones does not work, and volume change would sometimes get stuck. And sometimes it duplicates the streams on another system, which can be solved by killing the daemon.

Even with this less stable state, I agree that this is nothing compared to how bad the situation is in Mac or Windows world. In the professional environments I've been in, basically all people have given up on the system properly switching their device parameters correctly. So calls often need a few minutes to reconfigure audio. Same with external screen switching.

Re: The Linux audio stack demystified (and more)

#34

Post by boffinAudio »

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…

100% agree with you.

I have had a Linux-based DAW running in my studio, alongside the requisite MacOS and Windows machines, for decades now. It runs Ubuntu Studio, has superlative audio performance (72 channels of digital audio), and is a rock solid workhorse for doing large edits on tracks.

The key to it is in using Ubuntu Studio, which is a well-tuned distribution focused on superlative Audio performance, and to choose your hardware wisely. In my case, its all Presonus - because they have been Linux-friendly for a long time - and it easily delivers latency numbers that outperform even the Mac in the room.

Re: The Linux audio stack demystified (and more)

#35

Post by Pinus »

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’d say a lot of the complexity comes from the fact that there are at least four things — Jack, PulseAudio, Pipewire and the ALSA userland stuff, which the article fails to mention — that try to solve more or less the same problems (probably less, in the case of the ALSA userland). Add to this the fact that everything can be, and often is, run as a compatibility layer on top of (or below) everything else, and the naïve user who just wants to get some music though the speakers can be excused for feeling a bit dizzy.

Re: The Linux audio stack demystified (and more)

#36

Post by simoncion »

hparadiz wrote: post #32
bux93 wrote: post #30

Earlier quoted context omitted.

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,…

If Windows could do what Linux can out of the box VoiceMeter would not exist.

I assume you meant VB-Audio's "Voicemeeter"? If so, yeah, that's solid software, and it's NUTS that Windows hasn't made it unnecessary yet.

(For those who may be reading this comment and wondering what the shit this software is, go give it a look. (I use it regularly and don't do Pro Audio stuff... I just want to be able to independently adjust relative volumes of groups of software (like Voice Chat and Video Games).) If the software's feature set looks intriguing, do give it a try and use Voicemeeter Potato. IIRC, all "flavors" of Voicemeeter have the same trial period, and I can't think of any reason to not use the the "flavor" with the most knobs and interconnects.)

Re: The Linux audio stack demystified (and more)

#38

Post by bigstrat2003 »

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 believe I do, though I'm not certain. I have whatever is built into my Asus motherboard, which seems like it is ultimately a Realtek chip. Not sure though.

Re: The Linux audio stack demystified (and more)

#39

Post by Joker_vD »

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…

Well, I am glad it works for you. My Ubuntu setup at work, on the other hand, has recently picked up a habit of randomly switching to "Family 17h (Models 00h-0fh) HD Audio controller" which has nothing plugged into it instead of my actual headphones.

Re: The Linux audio stack demystified (and more)

#40

Post by p_l »

bux93 wrote: post #30
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,…

Intel Smart Audio is the worst, it takes over normal USB Audio devices and does its own weird processing on top, resulting sometimes with "hilarious" crashes.

And on corporate laptop you might not be able to disable its driver :/

Fortunately, it's too dumb to deal with devices that are behind more hubs than the root one...

Post reply on HN