Comment by kmarc | Hacker News Reader

Comment by kmarc | Hacker News Reader

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/...

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.

For me it's been nothing but problems. The primary reason is I'm probably doing things that (almost) nobody else is doing but I assume both countless people are and it should be working fine. Once I hook up some midi devices, want things to be recorded, run a synthesizer stack through pw-jack, expect the midi clock to go down the USB bus, etc, all kinds of interesting behavior starts happening. It even completely locked up my machine a few times. Like hard freeze. I had Audacity just nope right out. It somehow corrupted the local configuration and I had to blow it away to get it to start up again.

And then there's the whole new suite of programs you have to learn where their implementation is constantly in flux so the documentation isn't exactly accurate. pw-record for instance. That "--list-targets" option it tells you to use is long gone (that princess is now in the "wpctl status " castle). You gotta check the date of everything written online because the month it was written matters. It's still far from great.

I used an Amiga about 30 years ago to do similar things. Now that was something that genuinely just worked. People are still using it. That's how functional it was.

But like all these things, I should find the motivation to shutup the complaining and get to cracking on the code to make it suck less.

When it comes to linux and things are broken, your assumption on how many people have seen it and who is working on the section of code it's caused by is invariably an order of magnitude or two too high. That's why you can't find any fixes on the web. You're one the first to see it. Exciting, isn't it?

It would be helpful if folks on here who say "works for me"/"doesn't work for me" would indicate which flavour/version of Linux they use.

Some distros don't have the latest pipewire stack, and you're left to fend for yourself, having to follow some incomplete or poorly written blog post to side-step what your distro does and put pipewire on top.

Me: Ubuntu 24.04 LTS, and happily using carla, ardour, lmms and a bunch of midi devices with pw-jack. (I'm aware pw-jack is not required anymore, but that was my old workflow, and it speaks to the backwards-compatibility that the stack offers.)

Understood but I thought it was clear at least from my post that this isn't a distribution problem. I've certainly tried the distribution version, building from source, and various other things.

I have a counter-request: It's really frustrating when people are like "It just works! I had no problem! It's so easy!" in response to someone who has clearly struggled to get things working. It'd be like someone telling you they just had a car crash from a mechanical failure and you responding "Well I didn't! I drove home just fine!"

Instead, if you're going to respond at all, something like "I'm sorry, don't give up. I hope you figure it out" would be nice.

I hope you figure it out :)

I think the stars just aligned for me, and it worked. Not an expert at all on these things.

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 sounds can come from that? Now we're back into Linux!

I try to (poorly in my opinion) explore the uncharted, I'm not really looking to make a single penny.

Take for instance, the classic chaotic pendulum (https://m.youtube.com/watch?v=yQeQwwXXa7A), you can hook that up to an Arduino sensor pack and convert the values to midi notes that get piped through a synthesizer or they can be the filter control of the synthesizer.

How can the arrangement of the chaotic magnet surface affect the aesthetics of the sound?

For instance, if you hook the values up to a sequencer playing arpeggiators and limit the chord choice wisely, it kinda sounds like bach. Especially if you do time dilation and don't try for things to be real-time.

Recording a composition is a sequence of 2D diagrams with time signatures.

Here's another one, this time with synesthesia. You take a number of sticky notes in various colors and aim a camera at a wall and then assign different roles and rules to the colors and their adjacencies and do a similar pipeline but this time you're playing a concert by sticking post-its to a wall on top of each other.

And yet a 3rd. You take a couple hour capture of rush hour from a freeway traffic camera and assign instruments to the lanes, scale signatures to their densities and then you can hear an orchestration of Friday traffic.

In all these you're still "playing" music because you're taking an active role in a bunch of aesthetic decisions and constraints, it's just a new relationship.

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

I really want people to do their own!

Maybe I'll do a write-up on the setup to make it easier.

Really I look at things like musique concrete, BBC radiophonic workshop and John Cage and think that's where, a few decades removed, all the modern sound has come from that's been so dominant for the past 40 years or so.

I want to embrace the new and weird so 30 years from now I can help be a historical part of building whatever is coming next.

Tomorrow's all we got!

> which flavour/version of Linux they use.

> this isn't a distribution problem

Exactly. This all shouldn't be distro dependent when the only things involved are ALSA (kernel) and pipewire/pulseaudio.

Both unfortunately have distros do "things" to them all. Some default to dmix, some to direct hardware with PW/PA dynamically spawned and thus getting exclusive access for a single Unix user while the others are SOL, and other painful conundrums because they thought "we'll just do this and then it just works" for a single basic use case.

Would you use a distribution that doesn't prioritize the use-case for which you intend?

Use a Linux distribution that is intended for professional audio use.

>Once I hook up some midi devices, want things to be recorded, run a synthesizer stack through pw-jack, expect the midi clock to go down the USB bus, etc, all kinds of interesting behavior starts happening.

On Ubuntu Studio [0]/[1] - this Just Plain Works™, you know. I've been doing exactly this for years on my Ubuntu Studio machine, and I just don't have any of the issues you've encountered.

[0] - note that ubuntustudio is a metapackage you can install on most Ubuntu instances, which will set up audio for professional use.

[1] - see also, Zynthian: https://zynthian.org/

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.

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.

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.)

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...

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.

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 ?".

Sounds like HFP. For me on Ubuntu you can choose between audio playback profile and HFP in the sound settings ui, but maybe you have an app running that is changing that setting.

(Apologies for injecting advice into a grumbling thread)

No need to apologize, advice is good. Even if for now I'll keep Linux at what it's best: servers.

This happens exactly the same for instance on Mac or Windows with BT headphones, it's simply a fact of Bluetooth. If at any point you open an app that accesses the microphone of the earbuds / headphones, the format will downgrade from high-quality, playback only BT profile to a low-quality duplex profile. There's no high quality duplex audio profile in the Bluetooth protocol yet afaik, and certainly not implemented by any vendor. Just do t use Bluetooth if you care about sound quality is the answer.

Never had such issue on MacOs with the same headphones and the same apps running.

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

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.

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".

For me it all sometimes fall apart after suspend/resume and I am on a desktop, other than that I enjoy watching a movie with my wife with two pairs of Bluetooth headphones while having a USB attached microphone input overlaid so we can hear if our daughter went out of her room.

It's a mess not because it's complex, it's because of bad design.

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 single audio out, I would not bet on a beginner-to-intermediate ever getting it working, and PulseAudio is probably the main reason I in 2024 cannot recommend Linux on the desktop for non-engineers.

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.

> 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.

I get things like pulseaudio deciding only one ear is enough haha but emotionally I'm just grateful that it works at all sometimes since I really like the idea of a linux studio. Reboots help. I use a little bit older Ubuntu Studio, should probably upgrade. Back in the day when I only had alsa, I loved the experience.

Reply on news.ycombinator.com