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

101–110 of 136 posts

Re: The Linux audio stack demystified (and more)

#101

Post by shrimp_emoji »

JodieBenitez wrote: post #42
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…

That's the very first time I read "sanely-working-out-of-the-box" about Linux audio. I have a very different experience of course, such as "why do my BT headphones suddenly play everything at 8000hz sampling rate while I never asked for this and why the UI won't let me switch it back to 24khz ?".

BT headphones? BT is false dharma. Mobile shit. RF headphones work great on Linux because RF is true desktop dharma.

Re: The Linux audio stack demystified (and more)

#102

Post by vetinari »

dimsuz wrote: post #87
probablybetter wrote: post #68

The "mess" of Linux audio is due to ONE reason: single-client ALSA driver model. every other layer is a coping mechanism and the plurality and divergence of the FOSS community responds in various ways: - Jack - PulseAudio - PipeWire I am unclear why Jaroslav Kyocera chose to make ALSA single-client, but Apples CoreAudio multi-client driver model is the right way to do digital audio on general-purpose computing device…

Is this planned to be addressed/fixed? (single-client model) Maybe there were previous attempts?

No, because there's nothing to fix (at the system side).

Apps should use the right API from the right layer; when they skip something, no wonder they will miss whatever the skipped layer provides. When they do not need exclusive access to the device and want to play nice with the other apps, they should use pipewire/pulseaudio.

For 99% of apps, using ALSA directly is the wrong approach. You don't use IOKit directly in Mac apps either.

Re: The Linux audio stack demystified (and more)

#103

Post by prmoustache »

knorker wrote: post #64
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 think it's fair to say that your experience is extremely atypical. PulseAudio constantly stands out as the most common frustration in all of Linux. systemd is pretty frustrating too, but it's only frustrating the 1% of the time when it breaks (because it means your whole system is broken), whereas the 70% of the time PulseAudio doesn't work, it's more mildly infuriating. For anything except a single audio in and si…

I have been using pipewire for a few years already. Which distro are you using that is still using pulseaudio?

I can't complain really, in last decade audio has been working really well on my computer globally bar the occasional bluetooth pairing/connection issue. But I've seen people struggling with BT on all OS/platforms anyway. Pulseaudio was a PITA in the early years but matured a lot and Pipewire has been flawless on my distro since it took over. And I can do a lot of stuff out of the box that requires third party tools on other system to do the same.

Re: The Linux audio stack demystified (and more)

#104

Post by codedokode »

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…

This is probably wrong. ALSA is a low-level API that allows direct access to audio hardware, but only for one application at a time. ALSA has a kernel component and an userspace library that can be configured.

Pipewire uses ALSA to interface with audio hardware. But Pipewire also adds a plugin to an ALSA userspace library so that audio from apps that use ALSA API is rerouted to Pipewire. Pulseaudio did the same trick.

Re: The Linux audio stack demystified (and more)

#105

Post by codedokode »

I don't really understand how was JACK supposed to be used. On Windows or Mac you typically run a DAW and load plugins into it. But on Linux the user is supposed to run every plugin as a separate application and connect them using JACK? Doesn't this mean there would be lot of context switches? Also, in a DAW you can save your configuration, but how do you do this with JACK and a bunch of independent applications?

Also, given that Pulseadio and Pipewire both support ALSA clients, does it mean that the preferred API for applications should be ALSA? This way they can play sound on any system, even where there is no audio daemon.

Re: The Linux audio stack demystified (and more)

#106

Post by codedokode »

probablybetter wrote: post #68

The "mess" of Linux audio is due to ONE reason: single-client ALSA driver model. every other layer is a coping mechanism and the plurality and divergence of the FOSS community responds in various ways: - Jack - PulseAudio - PipeWire I am unclear why Jaroslav Kyocera chose to make ALSA single-client, but Apples CoreAudio multi-client driver model is the right way to do digital audio on general-purpose computing device…

Single-client model is not bad because it doesn't require kernel to do the mixing, sample rate conversion and they can be moved to userspace (which Windows does these days as well [1]). The less code in kernel, the better.

[1] https://learn.microsoft.com/en-us/windows/win32/coreaudio/us...

Re: The Linux audio stack demystified (and more)

#107

Post by codedokode »

miki123211 wrote: post #75
probablybetter wrote: post #68

The "mess" of Linux audio is due to ONE reason: single-client ALSA driver model. every other layer is a coping mechanism and the plurality and divergence of the FOSS community responds in various ways: - Jack - PulseAudio - PipeWire I am unclear why Jaroslav Kyocera chose to make ALSA single-client, but Apples CoreAudio multi-client driver model is the right way to do digital audio on general-purpose computing device…

> The "mess" of Linux audio is due to ONE reason: single-client ALSA driver model. This is one of the major reasons why Linux accessibility sucks IMO. Audio is one thing that you need to "just work™" if you want to get accessibility right, as there's no way for a screen reader user to fix it without having working audio in the first place[1]. On Linux, it does not "just work", and different screen readers have differ…

> the terminal Speakup screen reader (with a softsynth) wants exclusive control of your device through ALSA

If you have Pulseaudio or Pipewire, they add a plugin to ALSA library that reroutes audio to audio daemon, so ALSA applications should work correctly.

Re: The Linux audio stack demystified (and more)

#108

Post by codedokode »

vetinari wrote: post #102
dimsuz wrote: post #87

Earlier quoted context omitted.

Is this planned to be addressed/fixed? (single-client model) Maybe there were previous attempts?

No, because there's nothing to fix (at the system side). Apps should use the right API from the right layer; when they skip something, no wonder they will miss whatever the skipped layer provides. When they do not need exclusive access to the device and want to play nice with the other apps, they should use pipewire/pulseaudio. For 99% of apps, using ALSA directly is the wrong approach. You don't use IOKit directly i…

Pipewire/Pulseaudio install a plugin for ALSA library so that ALSA applications audio is rerouted to audio daemon. So apps using ALSA can work at both systems with and without an audio daemon.

Re: The Linux audio stack demystified (and more)

#109

Post by trelane »

erremerre wrote: post #95
freedomben wrote: post #90

Earlier quoted context omitted.

Realtek audio has gotten to a pretty good place on Linux. I've had several over the past few years, and they just work for the most part. Fedora, especially has been a wonderful out of the box experience for audio. Bluetooth on the other hand...

I must be the only unlucky one because my linux approved motherboard Intel DQ77MK with a Realtek ALC892 8-channel for audio kept switching between front and back panel (although nothing was plugged in on front) on Fedora 39 :( . It does work fine on windows.

Did you try OSX on the same hardware?

Re: The Linux audio stack demystified (and more)

#110

Post by bigstrat2003 »

knorker wrote: post #64
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 think it's fair to say that your experience is extremely atypical. PulseAudio constantly stands out as the most common frustration in all of Linux. systemd is pretty frustrating too, but it's only frustrating the 1% of the time when it breaks (because it means your whole system is broken), whereas the 70% of the time PulseAudio doesn't work, it's more mildly infuriating. For anything except a single audio in and si…

> whereas the 70% of the time PulseAudio doesn't work, it's more mildly infuriating.

I have installed Linux on I don't know how many systems at this point. My desktop, my work laptop, other people's work laptops, etc. Audio just worked flawlessly on each and every one. I cannot believe that PulseAudio has issues 70% of the time. There's simply no way I've been that lucky to have never seen an issue.

Post reply on HN