Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Linux audio stack demystified

blog.rtrace.io

Post reply on HN
Print view View original

51–59 of 59 posts

Re: The Linux audio stack demystified

#51

Post by Zamiel_Snawley »

An informative article for the Linux parts, I skipped the basics/intro.

I’d like to see some more detail on the rating chart, particularly on the axes where pipewire doesn’t surpass JACK/pulseaudio.

As an embedded software engineer who deals with processing at hundreds of kilohertz, it is funny hearing anything running Linux called “real time”.

If it’s not carefully coded on bare metal for well understood hardware, it’s not real time, it’s just low latency. No true Scotsman though(looking over my shoulder for the FPGA programmers).

Re: The Linux audio stack demystified

#52

Post by Zamiel_Snawley »

Modified3019 wrote: post #9
ruffyx64 wrote: post #2

Wrote this blog article as I needed to get a better understanding of the audio stack on Linux (esp. PipeWire, PulseAudio, ALSA, etc. ...). The article turned out to be a lenghty in-depth explanation of how audio works, how digital audio works, and what sound servers on linux actually do. Tried to write it in a way so it is accessible and understandable for beginners but also enlightening for experienced users. Hope i…

Learning by trying to teach is probably the best way to clarify and crystallize what we think we know. Always appreciate these kind of posts, especially since they tend to shine a line on all the contextual bullshit that experts take for granted. Right now I’m doing the same for an identification/contextual guide of local weeds and insects for seasonal scouts (I’m an agronomist). Unfortunately I find complexity tends…

A friend of mine who is a doctor said that when he was learning the saying was “watch one, do one, teach one.”

He made a morbid modification; “watch one, botch one, do one, teach one.”

Re: The Linux audio stack demystified

#53

Post by Zamiel_Snawley »

ladzoppelin wrote: post #6

"Professional audio will typicall utilize 24-bit. Everything higher than that is usually bogus. Bogus where only audiophiles will hear a difference." Does he mean internal DAW bit rates like 64/32bit float are bogus, I am probably reading it wrong ?

I don’t deal with audio, but I do use high frequency DACs/ADCs.

I have never found a DAC that actually has useful/detectable output differences above 16-18 bits. I’m not talking about audible, I mean with oscilloscopes. Many DACs take 32 bit inputs, but those extra bits aren’t useful in the real world.

The integral and differential non linearity of DACs in the real world make those extra bits misleading.

Re: The Linux audio stack demystified

#54

Post by amy-petrik-214 »

I can explain it much more simple

"At first Linus created /dev/dsp, and the user did smile upon him, and the user did see that it was good, and the user did see that it was simple, and people did use their sound, and people did pipe in and out sound as they did please, and Ken Thompson Shined upon them for following the way"

"Then the fiends got in on it and ruined it all, with needless complexities and configurations and situationships, with servers and daemons, and server and daemon wrappers to wrap the servers and daemons, and wrappers for those server wrappers, and then came security permissions for the server wrapper wrapper wrappers, why doesn't my sound work anymore, and then the server wrapper server wrapper wrapper server did need to be managed for massive added complexity, so initd was replaced by systemd, which solves the server wrapper wrapper server server wrapper through a highly complicated system of servers and services and wrappers"

RIP /dev/dsp you will be missed

- Kernighan 3:16

Re: The Linux audio stack demystified

#55

Post by PaulDavisThe1st »

foresto wrote: post #44
PaulDavisThe1st wrote: post #37

Earlier quoted context omitted.

There have been no cards that can do hardware mixing under production for more than 15 years. This is delusional. Also, the cards that could do that back in the day were, audio quality speaking, shite. If that's really what you consider "the best audio linux has ever", I think you don't know audio on linux very well. I will grant you one thing: if you did have one of those cards, it certainly made multiple applicatio…

> There have been no cards that can do hardware mixing under production for more than 15 years. This is delusional. I think you are mistaken. (And a bit rude.) https://us.creative.com/p/sound-blaster/sound-blaster-audigy...

Alright, fair enough.

That's totally the exception however, whereas back in, say, 2000, such devices were the norm. These days, the current crop of prosumer/proaudio audio interfaces (both PCI and USB) do not offer this sort of facility.

Yeah, that was a bit rude, sorry.

Re: The Linux audio stack demystified

#56

Post by Blackthorn »

amy-petrik-214 wrote: post #54

I can explain it much more simple "At first Linus created /dev/dsp, and the user did smile upon him, and the user did see that it was good, and the user did see that it was simple, and people did use their sound, and people did pipe in and out sound as they did please, and Ken Thompson Shined upon them for following the way" "Then the fiends got in on it and ruined it all, with needless complexities and configuration…

I'm not going to be routing 6 input streams into VSTs then out my stereo monitors with just /dev/dsp.

Re: The Linux audio stack demystified

#57

Post by LtWorf »

ssl-3 wrote: post #34
LtWorf wrote: post #32

Earlier quoted context omitted.

Yes the couple of clicks is the pairing. You have to pair.

Then this keybinding and device ID management business accomplishes what, exactly, other than exercising extra steps?

He likes to do it from command line. The steps are always the same.

Re: The Linux audio stack demystified

#58

Post by cogman10 »

imiric wrote: post #41
cogman10 wrote: post #13

Earlier quoted context omitted.

It's so clunky, IMO, because bluetooth is a dumbass protocol with things in the standard that should not be there (including which audio codecs are supported with which levels of bluetooth). Rather than just being a more simple network of wireless devices, it's a very complex protocol which makes everything more complicated. Why you may struggled could be anything from the firmware blob for your bluetooth device, to…

> It's so clunky, IMO, because bluetooth is a dumbass protocol with things in the standard that should not be there And yet GP has no issues on Windows... > Why you may struggled could be anything from the firmware blob for your bluetooth device, to the kernel driver installed, to bluez, to the sound server you are using. Any one of those things messing up will lead to a bad experience. Ah, so actually the complexity…

> And yet GP has no issues on Windows...

How well bluetooth works depends largely on the quality of drivers from chipset manufactures. As you can imagine, manufacturers put a priority on making sure their windows systems have well functioning drivers.

You'll also notice that Android (usually) has well functioning bluetooth drivers even though it's ultimately the same linux kernel under the covers.

> Ah, so actually the complexity and instability of the Linux audio stack _could_ be at fault after all. But let's blame the protocol instead, even though it works fine on other operating systems.

The linux audio stack doesn't help things, for sure, however a lot of the complexity between the audio stack and bluetooth revolves around the fact that bluetooth requires a well implemented driver for it to work well with the audio stack.

If you compare it to something like a regular sound card you'd quickly see why that's the case. For a sound card, the driver manufactures just need a driver that can convert PCM into soundwaves. The interface is quite simple which is why you generally don't see issues with the linux audio stack and a hard wired soundcard/chip.

That's why I blame the protocol more than the stack. The protocol is very complex (needlessly so). So instead of something that could just be "send these packets to this device" you have to hope and pray that the driver you are integrating with has properly coded up various codecs needed to talk to your headphones. Instead of just throwing a bitstream at a device you are now stuck with your audio stack negotiating with the driver about which codecs to select before sending in an audio signal. This is part of what adds complexity to the audio stack in the first place.

You end up with 2 routes for the audio stack, all other sound producing and receiving devices then bluetooth.

Post reply on HN