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

101–110 of 181 posts

Re: PulseAudio under the hood

#101

Post by makomk »

Latty wrote: post #24
kutkloon7 wrote: post #20

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's mostly historical - Ubuntu shipped it as the default when it was still unstable. This lead to a lot of people learning about it and lots of 'try killing pulseaudio if something goes wrong' advice. The reality now is it is very stable and has a huge number of powerful features. Personally I think it is great, and have no issues with it.

Part of the problem is that the early releases were pretty bad - sometimes even requiring patches that were only published in the Fedora package to work correctly (like, they literally hadn't upstreamed by the developers at all at the time). PulseAudio also didn't do bugfix-only releases, you either backported or waited for the next major release and hoped it didn't break anything else. They just released what I think is probably the first bugfix-only release in the project's history a couple of days ago. This certainly wasn't a case of the prior releases being so good they didn't need fixing either.

Re: PulseAudio under the hood

#102

Post by parrellel »

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…

What gets me though, is I never had a problem with Pulse Audio until I installed systemd.

Re: PulseAudio under the hood

#103

Post by digi_owl »

wereHamster wrote: post #84
notalaser wrote: post #81

Earlier quoted context omitted.

This has worked reliably in ALSA before it has worked reliably in PulseAudio (and, in fact, way before PulseAudio received any meaningful adoption, when Fedora enrolled everyone in PA's beta testing).

Well, maybe in the later days, but there was a long time when it didn't work well at all. I remember having to mess with the ALSA configuration to make it work. And then you also had apps which only supported OSS and getting them to work together with ALSA was an additional pain.

The reason for that was that while dmix was available for a long time, it was not enabled automatically on hardware without hardware mixing. More recent versions will silently (heh) enable it on hardware thats known to not have hardware mixing.

Re: PulseAudio under the hood

#104

Post by baldfat »

sigjuice wrote: post #94
justinsaccount wrote: post #51

Earlier quoted context omitted.

> Restarting PA does not help; have to reboot Then PA is not the problem, your sound card/drivers is.

How does one go about debugging something like this to pinpoint the root cause? I am just curious. I know nothing about PA (or even sound). Thanks!

How to debug PulseAudio problems

https://fedoraproject.org/wiki/How_to_debug_PulseAudio_probl...

Re: PulseAudio under the hood

#105

Post by makomk »

majewsky wrote: post #41
dom0 wrote: post #37

Earlier quoted context omitted.

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

The problem with PA is that (it appears like) there aren't really any simple errors. For most software, you have a bunch of common problems that you can find on Stackoverflow easily with a reliable solution. Pulse, on the other hand, while working fine on 99% of systems, usually fails catastrophically in creative ways on the remaining 1% and it's really hard to even understand what the problem is. (And of course, the…

Yeah, I've certainly had to learn a few tricks to debug audio issues on my Linux systems. Last one was a crash when disconnecting Bluetooth headphones, traced to PulseAudio unloading its Bluetooth plugin from code within the plugin. You don't get a backtrace if the crash is from returning into code that doesn't exist anymore. I still haven't figured out why this didn't cause crashes on all systems.

Factors which will have majorly affected people's PulseAudio experience over the years include audio hardware, what software they use with it, system uptime, local RF interference, use of suspend/resume, which patches their distro backported, and the exact stack and heap layout of the process on their system.

Re: PulseAudio under the hood

#106

Post by digi_owl »

toast0 wrote: post #67
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…

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)

Never mind that ESD and like is a leftover from the OSS days. Alsa has its own sofware mixer, dmix, that these days can be transparently inserted when the underlying hardware do not offer hardware mixing.

I wonder of Linux's biggest problem these days is the amount of "herd knowledge" that is floating around that is obsolete to say the least, yet is being used to justify some dev's latest weekend glory project.

Re: PulseAudio under the hood

#107

Post by mmjaa »

throwaway2048 wrote: post #100
clouddrover wrote: post #50

Earlier quoted context omitted.

> but I'll be darned if I'm going to ever try to use it again You probably won't have to. I think the long term plan is for Pipewire to replace PulseAudio (and be an alternative to JACK). Pipewire also does video. The initial release of Pipewire is video only with audio support to come: https://blogs.gnome.org/uraeus/2017/09/19/launching-pipewire... http://pipewire.org/ https://github.com/PipeWire/pipewire

cant wait for another 10 years of broken linux audio. Why not fix what we have rather than yet another rewrite with all its attendant exciting bugs.

For 15 years, I've had a totally stable, rock-solid, perfect Audio environment on Linux. My main DAW is Linux-based, and completely stable. Best latency of any platform, to boot.

So, just as a counterpoint, I'm guessing you're a Pulseaudio user ..

Re: PulseAudio under the hood

#108

Post by bandrami »

adambyrtek wrote: post #82
bandrami wrote: post #69

Earlier quoted context omitted.

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

> I still have difficulty believing that people actually use bluetooth for audio So you don't believe that somebody would like to be able to use wireless headphones?

Exactly. Why would you trade something that doesn't require power, has the most reliable, secure, and lossless transmission channel known, and is "configured" by plugging in hardware for something that requires power, has a less reliable transmission channel that can be easily snooped or forged, has to be configured in software? I literally don't understand why anyone would ever choose the latter.

Re: PulseAudio under the hood

#109

Post by bandrami »

Aissen wrote: post #83
fiddlerwoaroof wrote: post #80

Earlier quoted context omitted.

dmix works just fine for "normal users" and has since the first time I used it (sometime in 2005 or so)

How did you ensure one app wasn't much louder than the other ?

I'm trying to think of a software audio source that doesn't have its own volume control and I'm failing.

Re: PulseAudio under the hood

#110

Post by mmjaa »

clouddrover wrote: post #50
mmjaa wrote: post #5

I've never been a fan of PulseAudio, and always remove it and replace it with Jack on my Linux DAW systems, so this article wasn't really of interest to me .. until I started reading it. I think its the first time I've actually had any respect for PulseAudio as a framework .. but I'll be darned if I'm going to ever try to use it again. Jack just works so much better and with far less fuss and overhead .. still, I'm y…

> but I'll be darned if I'm going to ever try to use it again You probably won't have to. I think the long term plan is for Pipewire to replace PulseAudio (and be an alternative to JACK). Pipewire also does video. The initial release of Pipewire is video only with audio support to come: https://blogs.gnome.org/uraeus/2017/09/19/launching-pipewire... http://pipewire.org/ https://github.com/PipeWire/pipewire

Thanks for the heads-up, that is indeed useful and interesting to know .. hadn't heard much of it, but I suppose its because A) my Linux DAW is rock solid and I don't need to change it much, and B) I'm an iOS/AVFoundation developer by day-job, so this is not on my radar as much as it should be. Therefore, I'm quite grateful for the introduction to Pipewire; its going to make a very interesting, Monday-morning/train-ride read .. ;)
Post reply on HN