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

111–120 of 181 posts

Re: PulseAudio under the hood

#111

Post by bandrami »

hamax wrote: post #92
zeveb wrote: post #88

Earlier quoted context omitted.

I don't: wireless headphones seem strictly worse in every way than wired. They require batteries and charging; they introduce lag; they are expensive; they are easier to lose; they don't have a convenient cable to hang on to. I am completely and totally flabbergasted by their popularity. It's as though millions of people were turning their noses up at fine, free homemade French food and paying for McDonald's instead.

> seem strictly worse in every way than wired. The same as wifi, right? Strictly worse in every way. Except for the not needing wires way.

Wifi has encryption. Bluetooth means I'm broadcasting my audio stream to anybody who feels like snooping on me.

Re: PulseAudio under the hood

#112

Post by mmjaa »

baldfat wrote: post #23
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…

> JACK = less fuss WHAT? That is crazy talk. JACK is the most complected audio setup I have ever worked with. I owned a Record Label and a small studio. If you have to setup JACK from scratch it can get crazy complicated. Once you get it working it is an AWESOME framework but I only would ever see people needing low latency to ever really use it. JACK is 100% for a DAW (Digital Audio Workstation) and it is for low la…

Honestly, I guess its because I chose my hardware wisely - i.e. I use only very well-supported hardware components (in my case, Presonus/BridgeCo.), where high-capacity, low-latency audio was sort of implemented on Linux first and then ported to the other platforms .. so I'm looking at a current Firewire- based rig of 2 19" racks, full of gear, summing up to 40+ channels of audio over a single cable to the main DAW controller running Ardour.

In other words, I don't need no stinking' "game/consumer Audio", which is what Pulseaudio represents to me ..

Therein lies the beauty, I guess, of Linux - and of F/OSS creative-tools, in general ..

Re: PulseAudio under the hood

#113

Post by bandrami »

zeveb wrote: post #91
rhaps0dy wrote: post #77

Earlier quoted context omitted.

Or wise, and you take control of your own attention. Multiplexing can be handy if you like gaming, and having music from another application at the same time. Also sometimes it's useful to have a reference manual in one side of the screen and your text editor in the other, or a PDF viewer on one side and a LaTeX editor in the other.

I'm with you regarding the value of multiplexing. I don't use it much, but it was really annoying back in the day when one program would block another program's sound. > Also sometimes it's useful to have a reference manual in one side of the screen and your text editor in the other, or a PDF viewer on one side and a LaTeX editor in the other. True. An emacs which supported the framebuffer could do this (but GNU emac…

There are some framebuffer[1] consoles[2] that work really well when you do need to mux outside of X.

[1] https://www.freedesktop.org/wiki/Software/kmscon/

[2] https://code.google.com/archive/p/fbterm/

Re: PulseAudio under the hood

#114

Post by sigjuice »

baldfat wrote: post #104
sigjuice wrote: post #94

Earlier quoted context omitted.

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

Thanks! I just skimmed through this and discovered strace -k (Print the execution stack trace of the traced processes after each system call). TIL

Re: PulseAudio under the hood

#115

Post by traitormonkey »

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…

Super annoying! Fact is sound on linux used to 'just work' then pulseaudio came along and thensound on linux sucked ass and your 'naysayers' are people who spent days months years trying to get shit to work they had no right to hope to and engaged with their community but got nowhere - like all these things that get imposed people get ignored - they wouldn't be complaining if there wasn't an issue and obviously you hear them but because it doesn't affect you (much) everything is just fine - systemd garbage, unity crapola die in a fire, and pulseaudio. and maybe people understand the userland issues and maybe they aren't kernel devs but pulseaudio still sucks ass at the end of the day.

Re: PulseAudio under the hood

#116

Post by CoreXtreme »

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.

You can set one of them as fallback and it will remember, each time you plug the device. See: https://i.imgur.com/iazUIo8.png

Re: PulseAudio under the hood

#117

Post by InternetOfStuff »

parrellel wrote: post #102
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.

While I disagree with a lot of the Poettering-bashing that goes on, and the way it's expressed by some...

...he certainly seems to leave a trail of only-mostly-working yet ubiquitous software to the point that he is the only person whose name I associate with it.

Re: PulseAudio under the hood

#118

Post by loeg »

ro_sharp wrote: post #68
bandrami wrote: post #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…

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.

Well, it improved years ago (like, ten!) and I haven't had to worry about it in recent years.

I still remember buying a hardware sound card (soundblaster emu10k) to enable ALSA to mix multiple sources (game audio + teamspeak or whatever voice chat people used back then) back in the early 2000s.

Re: PulseAudio under the hood

#119

Post by AsyncAwait »

mmjaa wrote: post #112
baldfat wrote: post #23

Earlier quoted context omitted.

> JACK = less fuss WHAT? That is crazy talk. JACK is the most complected audio setup I have ever worked with. I owned a Record Label and a small studio. If you have to setup JACK from scratch it can get crazy complicated. Once you get it working it is an AWESOME framework but I only would ever see people needing low latency to ever really use it. JACK is 100% for a DAW (Digital Audio Workstation) and it is for low la…

Honestly, I guess its because I chose my hardware wisely - i.e. I use only very well-supported hardware components (in my case, Presonus/BridgeCo.), where high-capacity, low-latency audio was sort of implemented on Linux first and then ported to the other platforms .. so I'm looking at a current Firewire- based rig of 2 19" racks, full of gear, summing up to 40+ channels of audio over a single cable to the main DAW c…

> Honestly, I guess its because I chose my hardware wisely

In that case, you can also chose hardware that works well with PA, so I don't see JACKs benefit there. Also, I don't think they're equivalent in functionality.

Re: PulseAudio under the hood

#120

Post by loeg »

simias wrote: post #87
lathiat wrote: post #76

Earlier quoted context omitted.

Spoken confidently like someone that never tried to play sound in two applications at once.

I keep seeing this argument in this thread and quite frankly I'm dumbfounded. Last time I've had this issue was more than a decade ago on FreeBSD and it was solved by tweaking my OSS config to enable multiple channels. I've never, ever had this issue with Alsa. And I'm not a fan of Alsa either, PA just managed to be even more opaque and less reliable in my experience. Now, it's just anecdotic evidence of course but b…

FreeBSD's OSS is not ALSA.

ALSA refused to do mixing in software for some time. Maybe it still doesn't do it, I don't know. So if you had a hardware sound card that would do mixing, you could play multiple channels with ALSA, but if you didn't, you were SOL.

Post reply on HN