Live data from Hacker News

PulseAudio under the hood

gavv.github.io

61–70 of 181 posts

Re: PulseAudio under the hood

#61

Ugh, the annoying PulseAudio that sometimes makes your volume suddenly much louder or much softer when you want to change it by just one notch, just because it wants to try to be "smart" with different applications or whatever thing I don't care about it is that it tries to do, there should be 1 volume slider and it should work correctly period (and without lag - another thing PulseAudio introduced). Oh how I miss th…

The issue with the volume is one of your desktop environment, not of PulseAudio.

Re: PulseAudio under the hood

#62

Related: "Launching Pipewire" [0], which is meant to (among other things) eventually replace PulseAudio. [0]: https://blogs.gnome.org/uraeus/2017/09/19/launching-pipewire...

GDIt. This, this is why Linux is not on the desktop. Constant CADT churn.

Like MMAudio, DirectSound, Kernel Streaming, WASAPI?

AudioTrack, OpenSL, whatever-the-Android-8-thing-is-called?

Re: PulseAudio under the hood

#63

I am quite surprised that PulseAudio has a bad reputation. I couldn't get ALSA working on Arch Linux, and simply installing PulseAudio resolved all my issues. From the sentiment here I get the feeling that it might stop working any moment.

It use to be terrible. Steam games would generate static, you'd occasionally get video/audio lag, etc.

I started really using it when I started using Linux laptops, just because it's way easier to connect bluetooth audio, ship audio over HDMI, etc.

It actually works pretty well now and I like it. Still hate and refuse to use systemd though. :-P

Re: PulseAudio under the hood

#64
post #39

Earlier quoted context omitted.

OSX remembers per device settings and reapplies them when the new device is visible. I haven't used windows seriously in 15 years. Linux has really bad UX most of the time. OSX is the best of the worst.

I've stopped counting how often OS X moves audio streams to the wrong headset on my work notebook.

it will remember volume levels for various configurations. I stand by best of the worst.

Re: PulseAudio under the hood

#65
post #4

It took me about a month of on/off attempts to get audio to stop routing through HDMI every time my desktop came out of suspend and I still have a basic understanding on how the audio system works on my machine. While I praise the open source community for everything they've done it's still really hard for even an advanced user to understand how things work. Its flabbergasting at how it has reached this situation.

I've only dealt with this on Intel chipset HDMI - if I'm remembering correctly there's some part of the snd_hda_intel kernel modules you can blacklist in order to disable this.

Re: PulseAudio under the hood

#66
Sigh.

Once upon a time, sound cards were files in the /dev tree. To play sound, you wrote pcm data to the file representing a sink. To record, you read pcm data from a file representing a source. Things were better then. I'm sure there are people with use cases that have required the four (and counting!) solutions crufted on since then, but I've never been one of them, and it irks me that the interfaces get more and more complex and brittle with each iteration.

Re: PulseAudio under the hood

#67

PulseAudio posts are always filled with naysayers; the vast vast vast majority of users (like systemd in this regard) have no idea it's even running and just get on with whatever they're doing. I've primarily run Linux over the last fifteen or so years and barely had an issue that's directly PA's fault. I remember the bad old days where a playlist would finish and then GAIM's notification sound would bleat fifteen ti…

I usually had sound cards with hardware mixing, but what was wrong with esd? It did software mixing and seemed to work. (And didn't require you to run the rest of enlightenment, despite the name)

Re: PulseAudio under the hood

#68

Sigh. Once upon a time, sound cards were files in the /dev tree. To play sound, you wrote pcm data to the file representing a sink. To record, you read pcm data from a file representing a source. Things were better then. I'm sure there are people with use cases that have required the four (and counting!) solutions crufted on since then, but I've never been one of them, and it irks me that the interfaces get more and…

I think the use cases you're describing are quite distinct from a "Linux on the desktop" user. The audio experience for this kind of user (myself included) has improved dramatically in the past few years.

Re: PulseAudio under the hood

#69

Sigh. Once upon a time, sound cards were files in the /dev tree. To play sound, you wrote pcm data to the file representing a sink. To record, you read pcm data from a file representing a source. Things were better then. I'm sure there are people with use cases that have required the four (and counting!) solutions crufted on since then, but I've never been one of them, and it irks me that the interfaces get more and…

I think the use cases you're describing are quite distinct from a "Linux on the desktop" user. The audio experience for this kind of user (myself included) has improved dramatically in the past few years.

I'm a desktop Linux user; I preferred the old way. I do get that most people like multiplexing (I don't; I want exactly one sound source at a given time), and I'll grant that has improved.

I banged my head against my desk for a couple of days when Slackware switched to Pulse with 14.2, allegedly because it was needed for bluetooth. I still have difficulty believing that people actually use bluetooth for audio, but apparently some people love it.

Re: PulseAudio under the hood

#70
post #31
post #14

Earlier quoted context omitted.

PulseAudio is the only audio system I have used that can stop recognizing output hardware (on the motherboard!) without a reboot. On the worst of its competitors, you can be assured that once you get it working, it continues to work at least until reboot, and usually until you change config or upgrade the wrong package.

I get that occasionally when putting my laptop to sleep with a HDMI cable plugged in, then waking it up with the HDMI cable unplugged. I've found killing the PulseAudio pid (systemd restarts it) usually fixes it. Weirdly trying to restart it properly through systemd doesn't work but YMMV This is on ArchLinux running KDE4

[deleted]
Post reply on HN