PulseAudio under the hood | Hacker News Reader

PulseAudio under the hood

gavv.github.io

271 pointsdaenney171 comments

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.

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 network audio streaming. None whatsoever. Didn't even have a hint the support for those autoconf protocols existed.

I did once try to stream a Pulseaudio stream from one linux system to another. I never got so much as a peep to go across. I have no idea where any diagnostic messages may have gone that might help me debug this. I have no access to a working configuration to compare to. I have no idea what I did wrong and no idea how to fix it. I can find documentation that assumes you're writing C extensions and I can find documentation on how to slide sliders in the Gnome volume app, but I can't find anything in between. And I'm a professional software engineer with a minor in electronic music; there are certainly people with more knowledge and more motivation on these matters than me, but on the flip side, features that I can't figure out or get working might as well not exist to the vast majority of the population.

So while I'm not asking you to write a manual page, how exactly did you get to the point where you can do that? Again, I'm serious; the previous paragraphs are not to just slag on a project, but to show where I am and what problems I'm having. I've got a project I'm trying to do where it would be really useful to understand these things, but I have no idea even where to look at this point. (I've poked in every Google search I can think of and gotten the aforementioned C-API level docs or "I just installed Ubuntu, how do I volume?" docs.)

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! :)

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.

So, basically impossible for normal people.

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.

In addition to the fully open options; you can connect to AirPlay devices with PulseAudio if you have the module for it installed. Not sure if it's default on many distros since I use Arch (where little to nothing is installed by default).

> So, this is an honest question, not an attempt to be cruel: How exactly do you get that to happen?

The other answer is way better than mine, but I will add what I also said elsewhere in this thread: In 99% of cases, Pulse just works. In 1% of cases, it fails in catastrophic, bizarre and utterly undebuggable ways. I have the luck of being in the 99%.

I just installed and started Avahi and selected "Make network sound devices available locally" (or whatever the option is called) in paprefs.

That's for the client part. For the server part, see https://github.com/majewsky/system-configuration/blob/master... (that's for Arch Linux, package names etc. might differ between distributions).

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

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 yet to see a "Jack under the hood" article nearly as impressive as this one.

> 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 latency. Pulse is for the rest. I have found that the legacy of a poor initial deployment has been a heavy chain around its neck just like KDE 4, RPM (for having an issue for a few months over 10 years ago) and now Systemd (Systemd had a fine performance roll-out but philosophy issues).

Pulse has excellent integration with jackd:

  /usr/lib/pulse-11.1/modules/module-jack-sink.so

  /usr/lib/pulse-11.1/modules/module-jack-source.so

  /usr/lib/pulse-11.1/modules/module-jackdbus-detect.so

I can use pavucontrol with ease to redirect an application's audio output (e.g. chromium's) to the jack sink.

It's a painful process to accomplish the same thing without using pulseaudio, because you're going to have to mess with ALSA configuration files- and believe me, that's no fun at all.

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

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

Perhaps the point is that I set up jack for my system first, and Pulseaudio lags behind in terms of, jack is my dependency.

However, its moot - this is not consumer audio. Its more, "studio production audio"...

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

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

Nah, more a general observation of the CADT that is so painfully prevalent in Linux userspace...

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

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

Checked on their Freenode channel. They are looking at not total replacement but will replace certain features.

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.

Now extrapolate this to the same author's init system that controls how your machine boots. He didn't become much better programmer since then.

That's odd. I found my Linux system always got HDMI audio right while Windows always got it wrong. I seem to recall I was able to force VLC to go to the right place by adding it to a config file, but the system sound never did work right on Windows...I had to manually select HDMI every time it got plugged back in.

You had the wrong default selected in Windows mixer.

Need to select it as default when plugged and whenever it gets replugged it retake its priority. Works as expected with multiple default / temporarily plugged devices.

Interface might need a bit of a clean up though.

I think it was a buggy driver more than a Windows problem, as I tried selecting it as the default. It sometimes wouldn't show up when re-plugged in, as well. I'd even have to reboot sometimes to get it to show up as an option.

Doesn't work for me (not the person you are replying to) - every time I change input on my monitors Windows starts trying to use them for audio - doesn't matter what default I set, even disabling them.

I can second that. I'm by no means a fan of PulseAudio, I got bitten by it many times in the past, but my experience with Windows and audio over HDMI has been at least as bad. Even with a fully updated Windows 10 and a bog-standard on-board audio chip, Windows consistently messes up my speaker configuration or randomly mutes the audio. Particularly after updates it regularly forgets that I have a 5.1 receiver hooked up over HDMI and defaults back to stereo, and I have to re-configure it again.

I felt like that when I couldn't configure GNOME to shutdown when I hit the power-button on my chassis, I could only pick to suspend.

It is not possible to change the power settings and it was removed by the GNOME developers[0] (the shutdown/power off action was considered too destructive[1]).

Bottom line: You can no longer power off your laptop by pressing the power off button.

[0] https://bugzilla.gnome.org/show_bug.cgi?id=755953

[1] https://github.com/GNOME/gnome-settings-daemon/commit/69d9d8...

Well, technically you can still power it down with the power button, but that's not so graceful to say the least.

FWIW I have the same issue on osx. :)

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.

I've stopped counting how often OS X moves audio streams to the wrong headset on my work notebook.

it will remember volume levels for various configurations. I stand by best of the worst.

Does OS X even have an OS level volume mixer? Can I set my background music to be 20% of my video game without going into each of their inbuilt volume sliders? Can I move apps between audio devices? In a showdown between OS X, Windows and Pulse for audio setups as a consumer, OS X comes dead last and I use all 3 regularly.

I've only dealt with this on Intel chipset HDMI - if I'm remembering correctly there's some part of the snd_hda_intel kernel modules you can blacklist in order to disable this.

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

Just a note that PulseAudio maintainer Tanu Kaskinen is on Patreon [1]. He publishes monthly notes on PulseAudio changes there first and wouldn't mind people supporting him via Patreon.

[1] https://www.patreon.com/tanuk

Ugh, the annoying PulseAudio that sometimes makes your volume suddenly much louder or much softer when you want to change it by just one notch, just because it wants to try to be "smart" with different applications or whatever thing I don't care about it is that it tries to do, there should be 1 volume slider and it should work correctly period (and without lag - another thing PulseAudio introduced).

Oh how I miss the simplicity and elegance of before PulseAudio (and its evil twin "hi-let-me-put-your-text-logs-in-a-binary-format"-systemd) appeared in ArchLinux.

The issue with the volume is one of your desktop environment, not of PulseAudio.

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 times. PA saw an end to that.

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.

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, these 1% will shape public opinion. A large portion of the 99% is not even aware they're using Pulse.)

Two nines isn't very many nines. I've had problems with PA 100% of the time. Must be me, right? The only PA solution I know is purging it from my system.

what people mean when they say the vast majority of people dont have problems is "I don't care about your objectively broken experience"

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.

You should install apulse and run that with Firefox! Works like a charm.

You can also compile FF with ALSA enabled. Gentoo has a useflag for that.

This is the better option (aside from fixing your PA config in the first place, which I'd heavily recommend instead). apulse can get into issues with Firefox's sandboxing. It supports PulseAudio and works with ALSA too, but ALSA-pretending-to-be-PA won't work.

But really, fix your PulseAudio instead.

In theory yes. But compiling Firefox is just a mess.

./mach bootstrap && ./mach build

You can just use your distribution's package manager for that.

I thought they had plans to deprecate the build flag in a later version, but can't find verification.

It will in any case not get any maintenance, so expect things to break with no recourse as new versions are released.

This similar to how on paper Firefox can still be compiled with GTK2, but it is not supported.

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

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

> Firefox stopped supporting ALSA, so I had to install PA

PulseAudio emulation for ALSA https://github.com/i-rinat/apulse

I remember when PulseAudio came out. I loved it! I could actually have two programs open playing audio at the same time[0]. The future was now.

[0] If I remember correctly, this was due to driver issues, but somehow PA just handled it.

Old versions of ALSA only supported one input, but that's been a solved problem for a decade.

At least.

Older versions supplied dmix but didn't automatically enable it. Newer versions are supposed to autoenable it on audio devices without hardware mixing.

Frankly the only thing PA brought to the table was the ability to handle multiple audio devices while there is ongoing audio IO. Primarily in relation to usb headphones/headsets. But then that class of hardware is its own kind of abomination in the first place.

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)

Oh, it did not work good for many use cases, and even in the supported use cases it had pretty severe bugs. PA is also way more power efficient.

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.

> Never mind that ESD and like is a leftover from the OSS days.

I never had many problems with OSS either. :) I'm bringing up esd because I was misrembering that when pulseaudio came on the scene, it seemed to be already existing, not screwing up too badly, and addressing the commonly held up use case of software mixing.

After reading notalaser's fine summary [1], I'm realizing I've lumped 'ALSA broke everything that I already had working (but did eventually work, and support newer hardware)' and 'PulseAudio broke everything that I already had working' together in time in my mind, when really things were many years apart. It seems that by the time PulseAudio came out / was widely pushed, ALSA had already subsumed esd (unless you were using the network audio features), so the most often reported 'great thing' doesn't sound like something people wouldn't have had.

[1] https://news.ycombinator.com/item?id=13382152

For me, personally, the bad old days before PA was OSS, when an application could squat on the audio hardware and absolutely disallow any other software from playing any sounds at all on the system until it was stopped or forcibly killed. And good luck finding which piece of software was claiming absolute ownership of your sound card.

PA gives me the ability to have multiple pieces of software making noise at once, a software mixer with per-application and per-sound-hardware volume control which is completely divorced from those applications (so if I say MUTE, it is damn well MUTED), and the ability to choose where the sound is being output to. I cannot imagine anything doing better on the hardware I have.

Completely skipped ALSA and configuring DMIX, I guess? That at least provided software mixing.

To be more precise, that was the state of affairs with OSS on Linux. On FreeBSD, for example, the same OSS API has been providing transparently multiplexed output for many years. I don't even know how long, but I recall it already being there when I was fighting with dmux.

Perhaps not coincidentally, the primary sound API on FreeBSD is still OSS.

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

> I remember the bad old days where a playlist would finish and then GAIM's notification sound would bleat fifteen times. PA saw an end to that.

I too used Linux at that time and I remember that problem. The workaround in those days was to use esound. IIRC it also disappeared by the switch to alsa.

FreeBSD also doesn't have this problem, and it's still using the OSS api. Let's not confuse API with implimentation.

PA still randomly dies on my Thinkpad T420 running Ubuntu 17.04. I have to manually restart it several times in a day, and now I am really thinking of switching to a systemd/pulseaudio/RedHat influence free distro.

Try Debian on it, half the reason I switched away from Ubuntu years back was that it always seemed to have show stopping bugs like what you've experienced. I've yet to have PulseAudio crash on my T420, though sometimes it buffers audio when I walk too far from my bluetooth speaker.

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. If I set lfe-crossover-freq, I lose the bass on my headphones.

I found this patch

https://pw-emeril.freedesktop.org/patch/171424/

which seems solve the problem, but it was rejected.

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 have been developed.

Also, the feature would be hidden in a configuration file that is meant for advanced configuration anyways.

On top of that, I have a AV-receiver that does support all of this bass management. For every channel I can configure individual crossover frequencies, and I can but don't need to use a subwoofer. Why doesn't PulseAudio give me these freedoms?

Why would a free software developer deny others easy ways, or any ways at all, to configure their system? This is equivalent to the walled-garden approach of many closed systems. Why does this occur in free software?

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.

> Why would a free software developer deny others easy ways, or any ways at all, to configure their system?

Because of the "drive-by contributor" problem. Come by, drop off a patch that solves exactly your problem, never show up again to maintain the feature, even if it breaks, even if it's been broken for years.

That forces me, the developer, to either continuously test your patch (which I may not be able to do if I don't have your hardware/software/configuration/use-case-in-mind), or to shrug and hope it works. We have to just trust your initial work and have it no way weigh in on the future of our product?

We've learned too much as Open Source Software Engineers to just trust random drive-by contributions. We've gone from default-accept-all to default-deny, because at the end of the day that's what keeps quality in our software.

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 configuration files. That is stuff you abstract away.

It is of course possible that pulseaudio allows settings to be set that didn't exist before. It's API might be better for that - but that doesn't say you couldn't do the same with writing to configuration files if they had the same capabilities, like targeting a specific application (one of the use cases he mentions below).

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.

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.

It’s not volume sliding, but close to it. Having a button to move a running audio stream from speakers to headphones to network playback on my phone is amazing.

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.

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 more complex and brittle with each iteration.

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 apparently some people love it.

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

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 emacs currently only supports vt100, X, macOS & Windows, IIRC).

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/

There's nothing quite as jarring as having a pleasant piece of music turned up, only to have some off-key and out-of-time bell ding because an email arrived. Want to let me know there's a new email? Put a little envelope on the task bar so I can see it. Don't invade my music!

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

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.

As a matter of fact, my desktop & my laptop are both wired, and I hate how flaky WiFi is on my phone & tablet. Just moving to different rooms in my (small house) does horrible things to my network connexion speed — but Ethernet keeps on chugging along.

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

Not quite.

Bluetooth was originally encrypted, but gained the option of non-encrypted channels with version 1.1.

On top of that Bluetooth use frequency hopping.

Until recently there was no real hardware for scanning/sniffing Bluetooth traffic, at least not anything easily available compared to a wifi card in promiscuous mode.

Although...different use-cases there, for me. I've got a dozen audio sources, either connected to speakers (the TVs) or within a couple feet of me when I'm using it (phone, media player, tablet, laptop). So, a bunch of sources, a couple of which I might be listening to at once. All either in short enough distance for cords, or loud enough that it's moot.

Wifi: The internet comes from one (inconvenient) place in the home that I can't choose. I've got a couple of powerline ethernet adapters, but I've also got a lot of devices that handle wifi, but not ethernet. The choice is between using wifi or skipping the network connection. It's great as a last- (or only)-resort connection option, and it's usually sufficient, but then my uses for it are usually pretty tame anyhow.

Or want to play music from my laptop to my stereo speakers?

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.

I want to own exactly one wireless headset/microphone so that I can get up from my computer without having to excuse myself from voice chat.

Like a laptop or smartphone has over a stationary computer, wireless headsets have a freedom-of-movement benefit over wired.

> allegedly because it was needed for bluetooth

The bluetooth stack dropped support for ALSA with Bluez 5.0. About a year ago, dev started on a "bluez-alsa" or BlueALSA package the re-integrates an ALSA backend. I've used it briefly; it seems to work as advertised.

I think that Bluez 5.0 came out about the time that Slackware 14.0 did, so it makes some sense that versions before 14.2 would've provided Bluez 4.x for the bluetooth stack.

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.

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)

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

I haven't had a problem with that at all, so I'm not sure :)

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

Chrome, for example. Remember http://packet.city/ from a few days ago? All Chrome supports is mute or unmute.

Hm...

* default Alsa setup: set master to level that seems comfortable-- i.e., "to taste"

vs.

* default Pulse setup: set Chrome's app level to taste

Bug: packet.city plays an annoying sound with a perceived loudness that the user did not predict.

* Alsa solution: lower the master volume to a level that doesn't result in painful output from packet.city, and adjust all other apps accordingly

vs.

* Pulse: lower Chrome app audio, but leave yourself open to similarly unpredictable painful events from other apps

It seems in this case that the limitations of Alsa actually force the user to do the safe thing wrt perceived loudness.

Your proposed Alsa solution: Now all other apps with reasonable dynamic range, e.g., movies, are too quiet.

Then you tell your movie player to just make it louder, discarding that beautiful dynamic range. If you're paying close enough attention to the movie to care about the loss of dynamic range, then you probably aren't doing something else that might make sound, so you won't mind turning the master volume up.

At the same time, all other apps are at a level that won't cause painful audio to hit your ears.

If you trust VLC and you trust the video file you're watching, then turn the master audio back up during the loud "Universal Pictures" intro or whatever is an equivalent introductory sound at the beginning of the movie you're about to watch.

On my chromebook, there are two volume buttons and one mute button that are by far the most convenient way to adjust (master) audio for such a situation. So you turn down for random browsing and turn up for watching movies or whatever.

Btw-- those are almost certainly the controls someone would use to turn down or mute the sound of that horrible website audio listed above. In such a case the fact that pulse can give you an app volume for Chrome doesn't help anything-- for example, the user who adjusted Pulse app volume down to avoid pain will need to adjust it back up when watching a movie on Youtube for the same reason you mentioned. But they can't adjust the app volume with the keyboard controls. So to make use of that feature forces a more complicated UI that takes longer to use.

So how do you ensure that one tab wasn't much louder than the other?

In this case, it doesn't make much sense to treat the browser as a single application, but each site as one (does Chrome export each tab as a separate source to PA? IDK, I haven't checked). And, I can't think of a single thing that I actually want producing sound (and don't mind just muting) from my web browser that doesn't have its own volume control.

In my use, zero or one tabs is producing sound at any one time, so the distinction doesn't really matter to me.

And in most people's use, zero or one applications is producing sound at any one time, so the distinction doesn't really matter to them.

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.

What later days? Software mixing worked fine in ALSA in 2004-2005, and OSS emulation had been working reliably way before that. The first PulseAudio release was in 2004, and it wasn't adopted by Fedora until way, way later.

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 basic audio mixing is not exactly rocket science, you shouldn't need something as convoluted as PulseAudio to get it right. I mean, what the hell: https://gavv.github.io/blog/pulseaudio-under-the-hood/diagra...

Some power users might need these additional features, I don't. I wouldn't mind having all of that if the basics just worked reliably but they don't.

These days disabling PA is my go-to first step while troubleshooting audio issues on linux and more often than not I don't have to go to step #2.

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.

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

This has worked well in ALSA for years now. Now, ALSA won't let you set the volume of each application separately, but most applications have their own volume control for that anyway.

And you'll never have to deal with the application's volume Pulse's volume for that source disagreeing, and scratching your head as to why even though you set the volume to max, it isn't getting very loud. To be fair, maybe this has been entirely solved; the last time I used Pulse was ~5 years ago[0], so I might be a bit out of date. But not more out-of-date than the claim that ALSA can't play sound in two applications at once!

[0]: I don't have anything against Pulse, I just don't see the point in installing it. What does adding it to my stack get me?

Another "lovely" thing about PA is that will allow the loudest of the "apps" (groan) to ramp up the master control (do not recall the "feature" name right now).

Do wonder how much future hearing loss it has created by sudden spikes in volume...

Oh! When all of the GUIs say sound is at max, but it's either really quiet or silent, and it turns out that it's because even though the PA volume is up, somehow ALSA (which PA ultimately uses on the backend) got muted. But this is a PA box, so you have no GUI tools to set the ALSA volume!

You are talking about "flat-volumes", I also recommend disabling it. Even forgetting the issue you mentionned, it just makes volumes harder to handle and reason about.

I wonder if they would have ever implemented this "feature" if it wasn't the default (and only) behavior on Windows...

A massive sad part of all this is that so much of what is going on in Linux DE land right now seems to be driven by a pipe dream called multiseat. Or effectively using software to turn a Linux desktop install into a desktop mainframe.

This by attaching a bunch of peripherals and use software to assign them to groups that effectively form the equivalent of a graphical terminal.

All this supposedly in the hopes of introducing affordable computing to schools in the developing world. But said schools have already tested and discarded this idea, so why the DEs keep pushing it is a mystery.

Serious question: I remember claims that poorer countries basically switched to smartphones instead of PCs and phones are supposed surprisingly ubiquitous there. Can anybody confirm that?

Seats never made much sense to me and if the smartphone story has any truth to it, then I do not see any valid use case for that idea these days.

It's certainly true in urban India (and becoming more true in rural India). And this has the added bonus of bringing people into the banking system because you can store, send, and withdraw cash from your mobile account (this started in sub-saharan Africa but is becoming more of a thing in rural India too).

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

Well, sound mixing and resampling are a thing. Other operating systems do that where it belongs: in the kernel. OSS gets it right, for example.

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.

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 Windows users to do systems programming for Unix like operating systems.

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

Unplug a usb audio device, even unintentionally from a Windows PC and look at the havoc it can cause. Your media player is probably smart enough to handle it, your voip app is probably smart enough, your browser is maybe smart enough. Everything else though? Watch as it decides to play via HDMI to your speakerless monitor or crashes if that's not recognised as an audio device. Or crashes anyway. Or just never plays sound again until a reboot.

Thanks! This looks at first glance to be a useful guide for understanding Pulse. I plan on spending some time digging into it later.

Does anybody know if there's a similar such document for ALSA similarly written by someone who isn't an ALSA insider?

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 audio experience on Archlinux/Fedora, please pat yourself on the back because you're doing fine work.

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 Windows, anymore, of which I own several (a keyboard and an audio interface I'd planned to get rid of, but don't really need to now that I can do most things under Linux). Which is kinda funny...now Linux is more likely to work flawlessly with a given piece of audio equipment than Windows.

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

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.

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

Related: "Launching Pipewire" [0], which is meant to (among other things) eventually replace PulseAudio.

[0]: https://blogs.gnome.org/uraeus/2017/09/19/launching-pipewire...

As a naive user my response to that is "great, just as pulseaudio seems to be working properly and keeping out of the way; now we get something new with more bugs and less features".

>"We know that for many the original rollout of PulseAudio was painful and we do not want a repeat of that history." //

There's some hope!

GDIt. This, this is why Linux is not on the desktop. Constant CADT churn.

Like MMAudio, DirectSound, Kernel Streaming, WASAPI?

AudioTrack, OpenSL, whatever-the-Android-8-thing-is-called?

I've had mixed experiences with Pulse. Although kind of flaky, it has been super useful for me to handle audio from my Chrome browser that I run in a VM and display via X. I'm not aware of any other way to pipe audio across the network these days, other than the pulse tcp module.

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.

That is the reason indeed. For years Pulseaudio was a pain in the backside to use - not just on Ubuntu but on Debian as well. I still dislike it and think it's overengineered but today it works pretty well to be honest; as long as your setup isn't anything too exotic.

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.

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.

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

Haha, that is ridiculous!

I had to laugh - I'm using Ubuntu, and every time I want to listen to music (or watch a video, or play a game) I have to pulseaudio -k, because for some reason it boots up with some horrid 8-bit 22khz distortion over it all.

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 out PulseAudio wasn't a mandatory dependency for Okular, so I uninstalled it and everything worked perfectly again.

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.

It use to be terrible. Steam games would generate static, you'd occasionally get video/audio lag, etc.

I started really using it when I started using Linux laptops, just because it's way easier to connect bluetooth audio, ship audio over HDMI, etc.

It actually works pretty well now and I like it. Still hate and refuse to use systemd though. :-P

Tentacles, all the way down.

Reply on news.ycombinator.com