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

PulseAudio under the hood

gavv.github.io

Post reply on HN
Print view View original

31–40 of 181 posts

Re: PulseAudio under the hood

#31

Post by hnlmorg »

dsr_ wrote: post #14
sprash wrote: post #11

Loads of complexity. I don't see the value. Just give me files I can write data into and suddenly everything becomes very easy. Everybody knows how to write files. I know this discussion is getting really old but when Alsa was a step in the wrong direction, Pulse was the highspeed train in the wrong direction that followed, trying to "fix" it. This overengineered mess is the result of the tragedy allowing former Wind…

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

Re: PulseAudio under the hood

#32

Post by mrob »

kuschku wrote: post #12
onli wrote: post #2

He writes: A rich API provides methods for inspecting and controlling all available objects and their run-time and persistent properties. This makes it possible to replace configuration files with GUI tools. Many desktop environments provide such tools. That is wrong, if I don't misunderstand it. It does not matter much for the possibility of GUI tools whether they talk to an API or whether they parse and write confi…

There is a difference. Writing to config files doesn’t set properties at runtime. PulseAudio needs to allow UI tools to set properties with sub-second latency. And just reparsing the configs every time something is changed would be extremely wasteful.

Why do you need sub-second latency for something you're unlikely to do more than once a year?

Re: PulseAudio under the hood

#33

Post by kabes »

It would appear that I'm one of the few fans of pulseaudio here. Although I've only started using it since version 9, it always worked fine and we can do quite complex workflows easily. An example scenario:

1. We have multiple incoming RTSP stream where the audio is added as pulse audio streams.

2. We mix a couple of these streams.

3. We send this stream to an external echo cancellation device.

4. We take back the output of the echo cancellation device.

5. We mix some more streams into it

6. We route this to a certain output, which can be dynamically changed according to a certain algorithm.

We control PA using DBUS and the above scenario is accomplished with only a few calls. Granted, there's some latency you can't really control, but all in all it's an incredible powerful system that's been working really well for us.

Re: PulseAudio under the hood

#34

Post by kuschku »

mrob wrote: post #32
kuschku wrote: post #12

Earlier quoted context omitted.

There is a difference. Writing to config files doesn’t set properties at runtime. PulseAudio needs to allow UI tools to set properties with sub-second latency. And just reparsing the configs every time something is changed would be extremely wasteful.

Why do you need sub-second latency for something you're unlikely to do more than once a year?

Because I change parts of the config via the UI many times a day. In my case, because I have multiple audio cards and need to change several attributes.

Re: PulseAudio under the hood

#35

Post by cannam »

SwellJoe wrote: post #7
dijit wrote: post #3

Pulseaudio definitely needs to be demystified. As an average user it sometimes feels like black magic that sometimes doesn't do the right thing. But in recent years is been leaps and bounds better. I'm not sure whether that's due to distribution maintainers giving very sane configurations or that pulseaudio development has been focusing on sane defaults. Eitherway, if you're one of the people involved in giving me a…

I've got 20 years of hating audio on Linux at my back, so it's hard to let go of the pain, of which a significant amount was contributed by Pulseaudio. But, I have to agree that we finally (as of a couple years ago) have a good audio experience on Linux. It's good enough to where I don't even think about it anymore. I can even use pro-oriented audio software effectively. I can also use old devices that don't work on…

> If only an official REAPER port would come along (I know it'll run under WINE, but there's also been rumblings of a Linux port for years, and I'd much rather run something that works natively)...

There do appear to be official but as-yet unsupported Linux builds: https://wiki.cockos.com/wiki/index.php/REAPER_for_Linux

I had cause to try one for something small recently and it worked pretty well (including with PulseAudio). No idea how stable it is for serious use though.

Re: PulseAudio under the hood

#36

Post by SwellJoe »

squarefoot wrote: post #29
SwellJoe wrote: post #7

Earlier quoted context omitted.

I've got 20 years of hating audio on Linux at my back, so it's hard to let go of the pain, of which a significant amount was contributed by Pulseaudio. But, I have to agree that we finally (as of a couple years ago) have a good audio experience on Linux. It's good enough to where I don't even think about it anymore. I can even use pro-oriented audio software effectively. I can also use old devices that don't work on…

Reaper for Linux is already there. 100% native,no WINE required, and works great. http://wiki.cockos.com/wiki/index.php/REAPER_for_Linux

Cool. I didn't find that last time I went looking for the current state of REAPER on Linux, but I did find blog posts that indicated it was being worked on. That's exciting news.

Re: PulseAudio under the hood

#37

Post by dom0 »

petepete wrote: post #16

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…

Firefox stopped supporting ALSA, so I had to install PA. PA gives me: a noise chirp when the PA daemon starts, which is probably some uninitialized garbage buffer. Sometimes (I don't know what triggers it, seems to be random, and no, it's not the auto-suspend module which is on by default but seems to cause a similar bug for many people) audio starts to lag by .3-.5 seconds. Restarting PA does not help; have to reboot, which I can't/won't do for days at a time. This is supposed to be a Linux system, not Windows 98.

I don't hate PA. On another machine it was always installed. But it is quite clear to me that it is yet-another layer on top of the existing infrastructure, so it statistically will cause more issues than just the infra that's there already.

Re: PulseAudio under the hood

#38

Post by dom0 »

mrob wrote: post #32
kuschku wrote: post #12

Earlier quoted context omitted.

There is a difference. Writing to config files doesn’t set properties at runtime. PulseAudio needs to allow UI tools to set properties with sub-second latency. And just reparsing the configs every time something is changed would be extremely wasteful.

Why do you need sub-second latency for something you're unlikely to do more than once a year?

Properties like source/sink volume. It's bad UX if the adjustment is performed out-of-sync with the visual (volume slider) and manual (key press) feedback.

Re: PulseAudio under the hood

#39

Post by sitkack »

Latty wrote: post #25
drcross wrote: 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.

This isn't a problem only for FOSS - windows starts dumping my audio down my monitors whenever I change input on them, even if I specifically disable the device. I actually don't see any issues like that on arch with pulse.

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.

Re: PulseAudio under the hood

#40

Post by onli »

kuschku wrote: post #34
mrob wrote: post #32

Earlier quoted context omitted.

Why do you need sub-second latency for something you're unlikely to do more than once a year?

Because I change parts of the config via the UI many times a day. In my case, because I have multiple audio cards and need to change several attributes.

That's minuscule compared to how easy it is to parse config files vs to construct and speak to API. The volume slider UX is a better argument. That's the one thing I can think of where faster changes are indeed useful.
Post reply on HN