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

The Linux audio stack demystified (and more)

blog.rtrace.io

Post reply on HN
Print view View original

81–90 of 136 posts

Re: The Linux audio stack demystified (and more)

#81

Post by hawski »

kmarc wrote: 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 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.

Re: The Linux audio stack demystified (and more)

#82

Post by jcelerier »

JodieBenitez wrote: post #42
kmarc wrote: 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…

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

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.

Re: The Linux audio stack demystified (and more)

#83

Post by lynx23 »

miki123211 wrote: post #75
probablybetter wrote: post #68

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…

> The "mess" of Linux audio is due to ONE reason: single-client ALSA driver model. This is one of the major reasons why Linux accessibility sucks IMO. Audio is one thing that you need to "just work™" if you want to get accessibility right, as there's no way for a screen reader user to fix it without having working audio in the first place[1]. On Linux, it does not "just work", and different screen readers have differ…

I would be surprised if Orca did use Pulse directly, it uses speech-dispatcher (IIRC) which then uses PA if configured that way.

Also, Accessibility != Audio. I, for instance, use Braille only. No need for speech synthesis. So equating Accessibility issues wth the crazy audio stack is a little bit too simple.

Re: The Linux audio stack demystified (and more)

#84

Post by frabert »

jcelerier wrote: post #80
probablybetter wrote: post #68

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…

> current audio production systems have the DAW software directly opening an ALSA device. I mean, I remember this being the case for a very long time on windows with ASIO too, which is the only reasonable way to run a DAW with acceptable latency there. MacOS has multi-client but I was never able to get latency as low as fine-tuned windows and Linux systems, and in the end that's what matters - you just use your mothe…

My presonus interface allows multiple applications to access it over ASIO simultaneously, while letting regular Windows audio through, at 16 samples of latency. ASIO does not mandate exclusive access, bad drivers do.

Re: The Linux audio stack demystified (and more)

#85

Post by JodieBenitez »

jcelerier wrote: post #82
JodieBenitez wrote: post #42

Earlier quoted context omitted.

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

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

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

Re: The Linux audio stack demystified (and more)

#86

Post by JodieBenitez »

fulafel wrote: post #73
JodieBenitez wrote: post #42

Earlier quoted context omitted.

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.

Re: The Linux audio stack demystified (and more)

#87

Post by dimsuz »

probablybetter wrote: post #68

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…

Is this planned to be addressed/fixed? (single-client model) Maybe there were previous attempts?

Re: The Linux audio stack demystified (and more)

#88

Post by thriftwy »

oleg_antonyan wrote: post #20
g15jv2dp wrote: post #5

I now have flashbacks to when I tried to get sound working on my Gentoo install 15 years ago. It seems that now everything has changed (wtf is pipewire) and still requires arcane knowledge to get everything working smoothly...

PipeWire is drop-in replacement for pshshaudio with additional features (while preserving pshsh part sometimes). Only difference is 15 years ago half of the problems with sound were fixed by uninstalling pulseaudio as it was in early stages full of bugs but still pushed to many distros similar to systemd. Today's pipewire is as easy as uninstalling pulseaudio, installing pipewire, and most of the times it will contin…

Pulseaudio had a great GUI mixer/settings app. That does not seem to come with pipewire and tries to install PA when explicitly installed.

Re: The Linux audio stack demystified (and more)

#89

Post by tleb_ »

probablybetter wrote: post #68

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

Applications want to receive/provide a stream (X sample-rate, Y sample format, Z channels) and have it routed to the right destination, that probably is not configured with the same parameters. Having all applications responsible for handling this conversion is not doable. Having the kernel handle this conversion is not a good idea. The routing decision-making needs to be implemented somewhere as well. Let's not ignore the complexity involved in format negotiation as well.

The scenario of a DAW (pro-audio usage) is too specific to generalise from that. That is the only kind of software that really cares about codec configuration, latencies and picking its own routing (or rather to let the user pick routing from the DAW GUI).

Re: The Linux audio stack demystified (and more)

#90

Post by freedomben »

erremerre wrote: post #25
bigstrat2003 wrote: post #10

Earlier quoted context omitted.

To be honest, I wouldn't say it requires arcane knowledge these days. When setting up both Arch and Gentoo, I did a bit of research, determined that Pipewire was probably the best for me (because it seems to be largely a superset of the other options), and installed it following the wiki instructions. That's it. I haven't had to configure things in any sort of detail, it just worked smoothly the first time without an…

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

Post reply on HN