Live data from Hacker News

PulseAudio under the hood

gavv.github.io

141–150 of 181 posts

Re: PulseAudio under the hood

#141
post #52

Earlier quoted context omitted.

Seconded. When Pulse works, it's really magical. Like when you go to the hackerspace, connect to the Wifi, and the room speakers appear in your mixer and Just Work.

So, this is an honest question, not an attempt to be cruel: How exactly do you get that to happen? Because my reaction when I read the linked article was that pulse sure does seem to have a lot of features that sound pretty useful, but after years and years of nominally having it on my system in charge of my audio hardware, I have, to be blunt, absolutely no clue how to use any of those features, except a bit about n…

The hard thing is to have a Windows PulseAudio server and send all audio there.

Instructions here: https://parseq.co.uk/wordpress/archives/setting-up-pulseaudi...

It worked, but sadly, PulseAudio for Windows doesn't support 5.1 sound, only stereo.

Re: PulseAudio under the hood

#142
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…

Yeah, so far, every time I've even TRIED to get Jack to work... I can't even get the damn thing started on my system. I've read numerous SO posts, tried numerous things (YES. I've shutoff PulseAudio first.), and it's still sitting in my list of "Eventual annoying things to keep spending time on to get working."

No idea why you were down voted. JACK is certainly a VERY hard thing to get working. Why were you trying to use JACK?

http://jackaudio.org/faq/pulseaudio_and_jack.html

Re: PulseAudio under the hood

#143
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

> I think the long term plan is for Pipewire to replace PulseAudio

No that's not it at all. It's a framework that will use Pulseaudio OR Jack. Jack is only for low latency needs AKA Professional audio production.

"Pipewire is used to build a modular daemon that can be configured to: be a low-latency audio server with features like pulseaudio and/or jack.

https://github.com/PipeWire/pipewire/wiki

Re: PulseAudio under the hood

#144

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

> I think the long term plan is for Pipewire to replace PulseAudio No that's not it at all. It's a framework that will use Pulseaudio OR Jack. Jack is only for low latency needs AKA Professional audio production. "Pipewire is used to build a modular daemon that can be configured to: be a low-latency audio server with features like pulseaudio and/or jack. https://github.com/PipeWire/pipewire/wiki

What about that quote makes it seem like it will use pulse audio or JACK rather than acting as a replacement for them?

Re: PulseAudio under the hood

#145

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…

And what happened when two processes wrote to that file? And what if they where each in a different sample rate? ....

Re: PulseAudio under the hood

#146
post #98
post #21

I use headphones, and have tactile transducers on my chair. The transducers make the audio sound much louder than it actually is. That is good for your ears and your neighbours. Because of this setup I need full-range stereo output on my headphones and low-passed LFE for the transducers. How can I do this PulseAudio? When I enable lfe-remixing, I get full-range output on my transducers and I hear voices in my chair.…

I'd like to add that the patch was rejected because the maintainer had a use-case in mind, deemed the feature not a good solution, and therefore rejected the patch. I would comment directly on the site, but because the certificate is invalid, I cannot register an account. I don't like the attitude to reject a patch just because one can't come up with a use-case. Obviously there is a use-case, else the patch wouldn't…

Every single feature someone accepts into a code-base comes at a cost. That feature needs to be reviewed, tested and above all maintained and deal with any possible bugs that might arise from it. Especially open source developers only have limited amounts of time to spend on something. Investing time in this feature means not being able to invest time in something else.

Accepting a feature that a few people might use, hidden away somewhere in the advanced configurations, might very well not be worth the trade-off to them, even though you personally find the feature valuable. It has nothing to do with a walled garden.

Ultimately, if this is so important to you, you have the choice to fork and maintain it yourself and carry that cost. That'll most likely be a lot of work, especially if you want to keep in sync with upstream. But it might give you a better understanding of and appreciation for the tremendous amount of work and effort that goes into projects like these. Work that goes largely unpaid.

Re: PulseAudio under the hood

#147
post #33

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

Seconded. When Pulse works, it's really magical. Like when you go to the hackerspace, connect to the Wifi, and the room speakers appear in your mixer and Just Work.

"Magic" is apparently the key word there.

I've never had a good experience with Pulse, never had it work out of the box, and can never find information about configuring it. It gets uninstalled on every machine I run.

I stick with plain ALSA. It's annoying to configure, but IME it works out of the box and I usually don't have to worry about it.

Re: PulseAudio under the hood

#148
I've grown to really like PA. Originally I did not like PA because I thought it used more system resources over raw ALSA since it obviously came with a daemon running the background.. What I didn't know was that the libraries that applications used to interface with ALSA had all computation for sound mixing done in userland. So in a real world example, your audio player app using raw ALSA might use 10% of your cpu while playing audio. But using the pulse backend would cause your audio app to use 2% cpu with the pulse daemon using 3%. So its actually using less even though it is not obvious.

Once I started using PA, I kind of went crazy with it and started trying to add PA support to old linux software that was still ALSA only. The library and docs were not hard to use. The PA framework is all reference counted as well so when you create the pa-objects in C, you never really need to worry about memory allocation. It was pretty neat. Unfortunately, before I had all my commits and patches ready, I changed jobs and never got the free time to commit them the rest of the way.

Re: PulseAudio under the hood

#149
post #120

Earlier quoted context omitted.

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.

Alsa has had dmix for quite some time. The thing was that until something like a decade ago it had to be manually enabled via a .asoundrc edit. These days Alsa will enable it automatically on any device known to not have a hardware mixer.

Maybe so, but I did try to fix it without resorting to a hardware sound card and couldn't at the time. IIRC the syntax of the ALSA configuration files was particularly arcane.

Not sure why that deserves downvoting.

Re: PulseAudio under the hood

#150
post #124
post #30

Earlier quoted context omitted.

I had the opposite experience with Debian Sid a few days ago. I'd been using ALSA for everything without problems, but I was getting annoyed with the forced animations in Evince so I installed Okular instead (which has no forced animations). This brought in a big collection of dependencies, including PulseAudio. MPV immediately stopped working, even after manually configuring it for PulseAudio output. But it turned o…

okular is great for highlighting content etc but it is pretty resource-intensive.

On my 8 year old desktop system (8GB ram, 2.5GHz AMD Phenon II) it feels subjectively faster than Evince because of better UI latency. Resource-intensive is a good thing if the resources are used effectively, eg. for more aggressive speculative rendering, which seems to be the case. On mobile I might care a little more, but the forced animation in Evince (and a growing number of GNOME apps) is a deal-breaker, so I'd prefer Okular even on mobile.
Post reply on HN