Live data from Hacker News

The Linux audio stack demystified (and more)

blog.rtrace.io

91–100 of 136 posts

Re: The Linux audio stack demystified (and more)

#91

Am I the only one that sees unfriendly input/output channel names with Pipewire in client software? (Bitwig, Ardour, Reaper, more? I would like to see "Input 1" or "Channel 1" and not some strange ciphers when trying to assign things in a little dropdown selector in a DAW)

It seems to try to name the outputs based on the hardware name, but with multiple audio devices it can become quite confusing indeed. I've resorted to creating a wireplumber[1] config to rename things more reasonably and also disable a bunch of the inputs/outputs that I never use so they don't clutter up the lists.

[1] https://pipewire.pages.freedesktop.org/wireplumber/index.htm...

Re: The Linux audio stack demystified (and more)

#92
post #37

The text has a strong GPT-ish flavor.

Gpt is just emulating best writing quality. This article is very well written. If it was gpt generated, I'd be happy to read more like it.

I'd argue gpt emulates the lowest (i.e. cheapest to mass produce) passable quality writing optimized for longest page time/views

Re: The Linux audio stack demystified (and more)

#93
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…

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

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/

Re: The Linux audio stack demystified (and more)

#95

Earlier quoted context omitted.

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

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.

Re: The Linux audio stack demystified (and more)

#96
post #58

Earlier quoted context omitted.

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…

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…

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

Re: The Linux audio stack demystified (and more)

#97
post #76

Earlier quoted context omitted.

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…

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.

Re: The Linux audio stack demystified (and more)

#98

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…

> 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 devices running multi-tasking OS'es on application processors, in my opinion.

Because ALSA is a different layer in the audio stack than CoreAudio.

ALSA corresponds to MacOS drivers and I/O Kit.

CoreAudio (Audio Toolbox / Audio Unit) corresponds to Pipewire / Pulseaudio.

But on the Mac side everyone is OK with using CoreAudio (with the accompanying set of daemons), while on Linux, for some reason, everyone wants to go as low-level as possible, "just open the device file" and is wondering, why something is missing. Because you skipped that, that's why.

Re: The Linux audio stack demystified (and more)

#99
post #22

Earlier quoted context omitted.

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

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

Re: The Linux audio stack demystified (and more)

#100
post #33
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…

[deleted]
Post reply on HN