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

31–40 of 59 posts

Re: The Linux audio stack demystified

#31

Post by LtWorf »

anvuong wrote: post #5

Thanks for the nice writing. But do you have any insight on why is bluetooth audio so clunky on Linux? I'm using a pair of Sony XM4 and I have never had any problems on my 4 Windows machines. But on Ubuntu (both 22.04 and 24.04), I have had to jump through many hoops, from editing a bunch of config files, changing kernel flags, disable and enable a bunch of things I don't understand (mostly from reading Arch Wiki), j…

I have no issues with bluetooth. Just click on the device, associate and then it works. After the 1st time just being on is enough.

Re: The Linux audio stack demystified

#32

Post by LtWorf »

ssl-3 wrote: post #18
disinterred wrote: post #16

Earlier quoted context omitted.

I use arch linux and have never had an issue with pairing bluetooth with anything. In fact, imho, it works much smoother than Windows because I keybind bluetoothctl to connect to any bluetooth headphones, speakers, keyboard or whatever automatically using their bluetooth device IDs. To do this you must first pair them (I use the blueman-manager gui) and then get their bluetooth device ids and keybind the bluetoothctl…

I've never done much with Bluetooth under desktop Linux, but that sounds like a woeful pain in the ass compared to the usual steps for Android or Windows: 1. Pair headphones in a couple of clicks/taps; sound comes out.

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

Re: The Linux audio stack demystified

#33

Post by [deleted] »

brudgers wrote: post #3
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…

My experience: I'm interested in how Linux Audio works. The first half of the article covers other topics. It could be a separate article. An article focused on Linux Audio could say "For audio basics, click this link to my article on Audio Basics." Even for beginners, that's useful because even beginners just want to get sound out of their speakers and anatomy and physics lessons are in the way. It's ok to start wit…

[deleted]

Re: The Linux audio stack demystified

#34

Post by ssl-3 »

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

Earlier quoted context omitted.

I've never done much with Bluetooth under desktop Linux, but that sounds like a woeful pain in the ass compared to the usual steps for Android or Windows: 1. Pair headphones in a couple of clicks/taps; sound comes out.

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?

Re: The Linux audio stack demystified

#35

Post by jauntywundrkind »

Izkata wrote: post #30
jauntywundrkind wrote: post #22

Earlier quoted context omitted.

You can just pair as usual, yes, like any other OS, via a similar gui. And the device will then reconnect in the future. What the parent is describing is an advanced flow, that can be helpful if you have lots of computers & need to juggle bt devices. Setting up a hotkey just takes pre-work to setup. This workflow is optional. But it saves time & effort if for some reason you are one of the very few users who moves de…

A hotkey is more work than GP is describing. Pairing is a one-time thing, after that they connect automatically when the headphones are on and nearby. ...which, also, is exactly what mine do with Ubuntu. I used bluetoothctl to pair them once when I first got them, and when I turn them on Ubuntu automatically connects and switches the audio over. I don't have the same model headphones as GGGP, so I'm guessing it's a p…

I think we're actually somewhat in alignment, but when you say

> Pairing is a one-time thing,

You ignore the two scenarios I face regularly, that stem from me having lots of devices and lots of computers & wanting to switch around what's paired to what.

We both seem to be trying to defeat the notion that using Bluetooth in Linux is hard or special (it's not at all, it works like anywhere else, and these reports of it being hard are from people with at best extremely small domains of experience & knowledge).

I was trying to add that Linux has further upsides for when you do want to go further, and highlight & interpret the parent post to show how I have those issues & describe how adding hotkeys (something only Linux does) would help me, an advanced user juggling many systems & device. I've clarified my post to mention that auto-reconnecting will just work on most scenarios (but I get why some folks might think it's cool to have hotkeys).

Re: The Linux audio stack demystified

#36

Post by vetinari »

akira2501 wrote: post #26
OsrsNeedsf2P wrote: post #14

Earlier quoted context omitted.

Hardware gets more nuanced and Linux needs to accommodate it. Otherwise we'd be stuck with blurry fonts and no UI scaling like it's 2014

Consumer grade audio hardware has not gotten any more "nuanced" for several decades now. For the vast majority of use cases OSS was perfectly fine and it offered more than enough API to handle new features. For the small minority of uses cases where you might have two sound cards and you may want to do some kind of sample accurate combined production between the two at very low latencies, sure, OSS was _somewhat_ ina…

The OSS was inadequate the same day, when it was introduced; it couldn't even handle hardware available at the time (GUS, for example). It was really just mapping of the Soundblaster to a device file. For a single process, of course, all the others would have to wait, mute -- for mixing multiple inputs, you would need that dreaded daemon. Or GUS-like hardware, but with enough channels, so that yo won't run out of them. But then, mixing them in CPU is more effective, than pushing them all over external bus.

In a modern computer, you might have more sound cards than you are aware; the onboard sound codec, the outputs on your graphic card (that thing that pushes sound over DP/HDMI is a separate "sound card"), you might have some usb device (soundbars on monitors are usually usb sound devices), heck, even microphones from the last two decades have their own output. Webcam? Another sound device. Gamepad? That one too. And that's before anyone connects anything bluetooth. So it is not a small minority, in fact, it is the vast majority.

Audio stack boundary is in user space; period. It does stuff, that doesn't belong to kernel and is a perfect candidate for a daemon.

Re: The Linux audio stack demystified

#37

Post by PaulDavisThe1st »

miffe wrote: post #27
epx wrote: post #7

I miss the simplicity of OSS :\

Yeah, IMHO the best audio linux has ever was with OSS v3 and a soundcard that did hardware mixing. No software mixers like ESD or ARtS were needed.

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 applications all playing (same sample rate) audio at the same time as easy as it could be. But that's all.

Re: The Linux audio stack demystified

#38

Post by PaulDavisThe1st »

tialaramex wrote: post #12
swatcoder wrote: post #8

Earlier quoted context omitted.

I read them as talking about listening , as represented in mentioning audiophiles. The extra depth/range available in DAW's are useful for effects processing, mixing, and mastering and are a little colored by trying to squeeze max-performance DSP on a general-purpose/commodity CPU. I just don't take them as talking about that here though.

And the bits are basically free. If we had very cheap 24-bit floats and nothing bigger, maybe we'd use those, but we've got cheap 32-bit floats, so those are fine. The most important property of floating point is "infinite headroom". In integer space, sixteen times quieter means 4 fewer bits of audio, get the levels wrong badly enough and people can hear your mistake even if you fix it later - but in float space it b…

We would NOT use 24 bit floats since that would make them less than ideal at matching the hypothetical (and almost certainly never reach) 24 bit resolution of integer DAC/ADC hardware.

The reason why 32 bit floats work great is that they can handle a 24 bit integer without any loss, and then if for some reason the values get kicked up above the maximum you can represent there, you get subtle noise rather than heavy distortion.

Re: The Linux audio stack demystified

#39

Post by jauntywundrkind »

Venn1 wrote: post #25

No mention of AoIP. I make heavy use of Netjack2 in my production / streaming studio. Great way to move 25/30 channels of audio between 5 PCs in real-time. Beats the pants off DANTE.

PipeWire is starting to get AES67 support, which seems to be the audio and/or video streaming standard the industry is rallying around. PTPv2 vs DANTE's PTPv1, and just a much clearer protocol. I'm so excited for it! https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/AES...

There's a bunch of neat hardware listed in a ticket thread that folks have been playing with. Bluetooth to AES67 adapters, analog to AES67, whole huge video wall streamers. https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/32...

Re: The Linux audio stack demystified

#40

Post by akira2501 »

vetinari wrote: post #36
akira2501 wrote: post #26

Earlier quoted context omitted.

Consumer grade audio hardware has not gotten any more "nuanced" for several decades now. For the vast majority of use cases OSS was perfectly fine and it offered more than enough API to handle new features. For the small minority of uses cases where you might have two sound cards and you may want to do some kind of sample accurate combined production between the two at very low latencies, sure, OSS was _somewhat_ ina…

The OSS was inadequate the same day, when it was introduced; it couldn't even handle hardware available at the time (GUS, for example). It was really just mapping of the Soundblaster to a device file. For a single process, of course, all the others would have to wait, mute -- for mixing multiple inputs, you would need that dreaded daemon. Or GUS-like hardware, but with enough channels, so that yo won't run out of the…

> it couldn't even handle hardware available at the time

I would not call the GUS "consumer hardware." It was also the cast that most games offered support for it, but most companies did not put significant effort into it, and the support was either broken or buggy.

> For a single process, of course

ALSA is no different. dmix is purely in userspace. Which is why it has IPC keys that you can configure, and have to configure under certain circumstances.

> you would need that dreaded daemon.

You could use any of a number of different daemons depending on your particular use case and you weren't required to make one of them work or keep it compatible with your kernel driver versions. The OSS audio API was completely stable. The ALSA audio API eventually was.

> So it is not a small minority, in fact, it is the vast majority.

The import of my comparison is that the problem with OSS is attempting to use these cards /simultaneously/ in a "sample accurate and low latency way." OSS could, of course, handle multiple different cards and devices (easy as/dev/dsp0 vs /dev/dsp1). It did not offer any way to time them with a common reference, which made them inadequate for certain types of _professional recording_ scenarios.

You have not, so far, described anything OSS could not do.

> Audio stack boundary is in user space; period.

Yea, except the timing, which is the effectively the only benefit ALSA brings over OSS. Which, by the way, is a feature that is not at all in user space.

> that doesn't belong to kernel and is a perfect candidate for a daemon.

The one you dread?

Post reply on HN