Live data from Hacker News

The Linux audio stack demystified (and more)

blog.rtrace.io

111–120 of 136 posts

Re: The Linux audio stack demystified (and more)

#111

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…

I mean... I've never seen a single audio issue on Linux. It does "just work" in my experience. I realize the people citing issues in this thread aren't just making shit up for the fun of it, but I think there's a lot of going too far and saying it sucks for everyone when it seems to work just fine for most.

Re: The Linux audio stack demystified (and more)

#112
post #47
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 trying right now to connect a BT speaker to a RPi, while using mpg123 as a player. At least from the command line, it is all but easy. And I do not think what I’m doing is not the most basic scenario. Right now after coupling I have to restart mpg123.

I mean... it should work of course, and if it's not working for you then improvement is needed. But anything involving BT is most definitely not the most basic scenario. The most basic scenario is "plug speaker into sound card".

Re: The Linux audio stack demystified (and more)

#113

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.

Actually now that you mention it, I did have a similar problem on one particular motherboard. I don't attribute it to linux though so hadn't thought of it. It turned out to be a hardware issue (with the motherboard) though. The card kept resetting due to too low of input power. I had hoped a BIOS update would fix it, but it didn't. I have had a couple of built-in audio modules die and stop being seen by the kernel on old laptops.

Honestly I would just buy a USB interface. I got a Focusrite Scarlett 2i2 and have been very happy with it.

Re: The Linux audio stack demystified (and more)

#114
post #76

Earlier quoted context omitted.

Have you tried Linux audio forums/community? I think the problem is that, by experience, regular musicians will just say "you need to use windows (or mac) to do anything serious" so it's complicated to find enough people that are competent in both skills.

> Have you tried Linux audio forums/community Actually I've gotten everything to work adequately but claiming the alsa/pulse/jack to pipewire transition wasn't just a new nightmare would be wrong, well for me. > "you need to use windows (or mac) to do anything serious" Correct and maybe! Serious as in commercial or production? Yes! Serious as in exploration in HCI and digital instrument creation and what kind of new…

Do you have some repos and/or write-ups on these projects? That sound pretty cool.

Re: The Linux audio stack demystified (and more)

#115
post #79
post #52

Linux distros would be best off lifting as much as possible from the Android Open Source Project, i.e. a professional and streamlined Linux-based system that actually works and isn't just a mishmash of incompatible, poorly designed hobbyist trash. The year of the Linux desktop never arrived but most of the world has Linux sitting in our palms. Let's build on that instead of the dead ends of Debian, Slackware, etc.

Hasn't Android audio always struggled with input latency?

I use several audio apps on Android, on a mid-low phone. The most intensive use comes from Cubase - Audio and synths, mixer, inputs and outputs, midi/ phone input program. After 30 years on Atari then windows I've had my ups and downs with the program, but I can easily say that my android version is a1 solid, connected to/ from my hardware synths

Re: The Linux audio stack demystified (and more)

#117
post #17
post #15

Earlier quoted context omitted.

Well, time to move with the progress. I've been using KDE Wayland session for several years already.

nah I'm okay thanks. X11 still works flawlessly for me.

The main issue is that X11 is an increasingly unmaintained case and all new development happens with Wayland anyway. So as long as you can deal with lack of support - I guess no need to move, but otherwise Wayland with KDE has been well usable for a while already.

Re: The Linux audio stack demystified (and more)

#118
post #43

Earlier quoted context omitted.

I don't know what Pipewire is as well. I've used Linux daily for 10+ years, but I've never bothered to use Wayland.

Pipewire ends up being used to paper over Wayland deficiencies in some areas, thus why it's important for Wayland desktop ;) By itself it's essentially grand unification of audio servers that actually works better and is way less... opinionated about the only true way some things works, which was a problem with pulseaudio at times.

Separation of responsibilities is good, instead of having a mix of everything but not well enough situation with X11.

Re: The Linux audio stack demystified (and more)

#119
post #22

Earlier quoted context omitted.

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

If I had been using using linux as main OS in that situation, I would have had to reboot. How is that different?

It's different because this is windows hyper-v (or something related) crashing and bringing down your WSL session with it. A native Linux is far more stable.

Re: The Linux audio stack demystified (and more)

#120

Earlier quoted context omitted.

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.

At this day and age there should not be a system without an audio daemon. At least not one, that is not broken. Apps should not certainly accommodate for broken systems, and forcing workarounds for the correct ones.
Post reply on HN