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

41–50 of 59 posts

Re: The Linux audio stack demystified

#41

Post by imiric »

cogman10 wrote: post #13
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…

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

To be fair, I agree that BT is a mess. And I've personally also had bad experiences on Windows with it. But the insanity of the Linux audio stack is indefensible. It's a major part of the problem, even if BT were a flawless and simple protocol.

Re: The Linux audio stack demystified

#42

Post by opan »

OsrsNeedsf2P wrote: post #14
epx wrote: post #7

I miss the simplicity of OSS :\

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

>Otherwise we'd be stuck with blurry fonts

Things have only gotten worse as Pango has killed off bitmap font support. We already had crisp, clean, sharp, beautiful fonts, and apparently that upset some people who have more power than they ought to. Back in 2014 everything was grand. You have to choose your terminal emulator and other programs carefully now.

It's insane that people get monitors so pixel dense you can't use them normally, and post-scaling you have equal or less usable space to the monitors of old, just to avoid blurry fonts that didn't even need to be used in the first place. Then people try to use circular logic to justify it all.

Re: The Linux audio stack demystified

#43

Post by [deleted] »

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…

[deleted]

Re: The Linux audio stack demystified

#44

Post by foresto »

PaulDavisThe1st wrote: post #37
miffe wrote: post #27

Earlier quoted context omitted.

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

Re: The Linux audio stack demystified

#45

Post by mannyv »

So far the audio section is a great intro to audio and digitization, and applies to any a-to-d process at some level. Looking forward tomplowing through the rest.

The problem with audio is it's realtime (isochronous), which means good audio processing requires a guarantee of sorts. To get that guarantee requires a path through the system that's clear, which can be difficult to construct.

Re: The Linux audio stack demystified

#47

Post by mannyv »

mannyv wrote: post #45

So far the audio section is a great intro to audio and digitization, and applies to any a-to-d process at some level. Looking forward tomplowing through the rest. The problem with audio is it's realtime (isochronous), which means good audio processing requires a guarantee of sorts. To get that guarantee requires a path through the system that's clear, which can be difficult to construct.

Well, the rest of the article read a bit like a readme summary of the various audio daemons.

I was hoping to see more of the "how does linux audio guarantee low latency/time guarantees kids of things, especially when IPC is known to be slow?" What kids of shortcuts through the kernel are there to gwt those processing guarantees, if any? Etc etc.

Still, coming from someone who is clueless linux audio subsystems the article gave me a starting point so I know where to dig.

Re: The Linux audio stack demystified

#48

Post by quibono »

jpeloquin wrote: post #20
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 also have XM4's and they worked fine on Arch after addressing two problems: Do you dual boot? Different OS's on the same computer will generate different pairing keys even though they share the same MAC, and this will cause connection issues. Usually that's reported as having to re-pair every time you switch OS's though. https://unix.stackexchange.com/questions/255509/bluetooth-pa... I've also experienced audio ski…

Thank you for linking the SE thread! So this is the reason I've been having so much trouble with my Bt devices recently. I've used Linux as my daily for years but have also started dual-booting Windows as of a few weeks ago, and I've had to re-pair every single time I'd switch systems. I just chalked it up to just generic Bluetooth issues.

Re: The Linux audio stack demystified

#49

Post by tialaramex »

PaulDavisThe1st wrote: post #38
tialaramex wrote: post #12

Earlier quoted context omitted.

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

I don't think I agree. As you say, those extra few bits in your integer PCM are probably just noise, worse they might be correlated noise. They're not worthless, but I can't agree that they're automatically better than the infinite headroom option.

We don't have a world with 24-bit float DAWS, in our world stuff tends to offer 32-bit float, and so that's a no brainer, but just as I'm sure the 14-bit CD would have been perceived much the same as our world's 16-bit CD (bad engineers would do a bad job with it, good engineers would learn to use it well, some people would hate it for no reason), I think 24-bit float in the studio would have similar fans to 32-bit float.

Post reply on HN