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

71–80 of 181 posts

Re: PulseAudio under the hood

#71

Post by c0l0 »

jerf wrote: post #52
majewsky wrote: post #43

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…

PulseAudio (PA) is modular, and you can load new modules implementing new functionality at runtime via `pacmd` (and presumably other clients/config tools).

One of these modules that come with any standard distribution of recent-ish PA can use avahi/zeroconf (probably in part because avahi was Lennart P.'s previous focus of attention, before he started work on PA) to advertise PA sinks on the network. As a consequence, running the avahi daemon is required for PA network-wide advertising of its presence to work, and auto-discovery to have any chance of working at all. Another module implements accepting PA-via-TCP compliant clients via TCP. Both are included in PA's standard distribution, if it's recent-ish (think 2012 and later). Distros still might package them in extra packages; the Debian does so for the zeroconf-parts in a package named "pulseaudio-module-zeroconf".

To load the TCP transport support module and specify a primitive ACL (based on source IPv4 addresses - you need to adapt this ACL to your local environment if it uses another IP range!), you can use this `pacmd` stanza:

    load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;192.168.0.0/16 auth-anonymous=1
(A presumably more secure, cookie-based authentication mechanism with a shared secret involved is also available, but I've never used it.) This will make pulse open a listening TCP socket on port 4713. At this point, remote hosts with PA-ready applications should already be able to play back sound by setting the PULSE_SERVER environment variable to the accepting PA server's address - what's still missing is the avahi-based advertising of the service.

So, to make PA contact your system's avahi daemon and use it to advertise its sinks on the network, you load another module into your PA instance:

    load-module module-zeroconf-publish
If both these operations have succeeded (`pacmd` will complain loudly if they don't), a quick `avahi-browse -a` on a (avahi-enabled) host in the same network as the one with your exposed PA server in it should yield something like this (pasted from my local network):

    + enp0s31f6 IPv6 pulse@nas                                     PulseAudio Sound Server local
    + enp0s31f6 IPv6 pulse@nas: Jukebox                            PulseAudio Sound Sink local
    + enp0s31f6 IPv6 pulse@nas: Dummy Output                       PulseAudio Sound Sink local
    + enp0s31f6 IPv4 pulse@nas                                     PulseAudio Sound Server local
    + enp0s31f6 IPv4 pulse@nas: Jukebox                            PulseAudio Sound Sink local
    + enp0s31f6 IPv4 pulse@nas: Dummy Output                       PulseAudio Sound Sink local
    + enp0s31f6 IPv4 root@tv                                       PulseAudio Sound Server local
That is two hosts advertising PA sinks on the network - "tv" (running libreelec) and "nas" (running Debian).

Now, when you make another avahi-enabled host on the same network load the "module-zeroconf-discover" PA module, the advertised sinks should magically show up in that PA instance's list of available sinks. You can then move streams onto them with any of the standard utils, like pavucontrol.

If you've found a set of stanzas that set up your PA instances to your liking (with modules loaded the way your setup requires it), you can make them re-apply on daemon startup by persisting them in your user-specific rc files in ~/.config/pulse/.

Hth! :)

Re: PulseAudio under the hood

#72

Post by ashark »

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 was entirely happy with alsa and still don't know of any use-case I have that's better served by the more fragile, more resource-hungry PulseAudio. I assume it's useful to someone.

Re: PulseAudio under the hood

#73

Post by kbenson »

bandrami wrote: post #69
ro_sharp wrote: post #68

Earlier quoted context omitted.

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

> I don't; I want exactly one sound source at a given time

Really? So you want all app feedback to cease if you're playing music? No IM or new email notifications? That just seems like a pain to me.

Re: PulseAudio under the hood

#74

Post by jerf »

c0l0 wrote: post #71
jerf wrote: post #52

Earlier quoted context omitted.

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…

PulseAudio (PA) is modular, and you can load new modules implementing new functionality at runtime via `pacmd` (and presumably other clients/config tools). One of these modules that come with any standard distribution of recent-ish PA can use avahi/zeroconf (probably in part because avahi was Lennart P.'s previous focus of attention, before he started work on PA) to advertise PA sinks on the network. As a consequence…

In addition to the upvote already granted, I wanted to publicly thank you for trying to answer my question, because I love it when other people are polite this way. Thank you.

Re: PulseAudio under the hood

#75

Post by bandrami »

kbenson wrote: post #73
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 don't; I want exactly one sound source at a given time Really? So you want all app feedback to cease if you're playing music? No IM or new email notifications? That just seems like a pain to me.

I hate app feedback and notification sounds. I hate notifications in general; I prefer to poll for information I need on my schedule. This is also why I hate desktop environments and use a simple full screen window manager. One task at a time. Hell, lately I don't even bring up X every day if I don't need to. Tl;dr: I'm old.

Re: PulseAudio under the hood

#76

Post by lathiat »

ashark wrote: post #72
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 was entirely happy with alsa and still don't know of any use-case I have that's better served by the more fragile, more resource-hungry PulseAudio. I assume it's useful to someone.

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

Re: PulseAudio under the hood

#77

Post by rhaps0dy »

bandrami wrote: post #75
kbenson wrote: post #73

Earlier quoted context omitted.

> I don't; I want exactly one sound source at a given time Really? So you want all app feedback to cease if you're playing music? No IM or new email notifications? That just seems like a pain to me.

I hate app feedback and notification sounds. I hate notifications in general; I prefer to poll for information I need on my schedule. This is also why I hate desktop environments and use a simple full screen window manager. One task at a time. Hell, lately I don't even bring up X every day if I don't need to. Tl;dr: I'm old.

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.

Re: PulseAudio under the hood

#78

Post by ashark »

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.

In its initial (Ubuntu) release it would crash your desktop any time Firefox loaded a page that included flash content, which was a lot of pages back then. You had to choose between totally disabling Flash (again, kind of a big deal at the time) and attempting to excise PulseAudio and get Alsa's sanity back.

I chose the third way of dropping Desktop Linux. I just don't have time for that kind of crap anymore.

Re: PulseAudio under the hood

#80

Post by fiddlerwoaroof »

lathiat wrote: post #76
ashark wrote: post #72

Earlier quoted context omitted.

I was entirely happy with alsa and still don't know of any use-case I have that's better served by the more fragile, more resource-hungry PulseAudio. I assume it's useful to someone.

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

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