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.
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.
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).
> 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:
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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)
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.
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'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?
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).
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 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.
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.
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.
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.
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.
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)...
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." //
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.
[+] [-] kabes|8 years ago|reply
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.
[+] [-] majewsky|8 years ago|reply
[+] [-] mmjaa|8 years ago|reply
[+] [-] baldfat|8 years ago|reply
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).
[+] [-] clouddrover|8 years ago|reply
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
[+] [-] drcross|8 years ago|reply
[+] [-] SwellJoe|8 years ago|reply
[+] [-] kawsper|8 years ago|reply
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...
[+] [-] Latty|8 years ago|reply
[+] [-] pault|8 years ago|reply
[+] [-] CoreXtreme|8 years ago|reply
[+] [-] language|8 years ago|reply
[+] [-] dozzie|8 years ago|reply
[+] [-] sohkamyung|8 years ago|reply
[1] https://www.patreon.com/tanuk
[+] [-] Aardwolf|8 years ago|reply
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.
[+] [-] gcp|8 years ago|reply
[+] [-] petepete|8 years ago|reply
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.
[+] [-] dom0|8 years ago|reply
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.
[+] [-] asveikau|8 years ago|reply
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.
[+] [-] msla|8 years ago|reply
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.
[+] [-] toast0|8 years ago|reply
[+] [-] cuddlybacon|8 years ago|reply
[0] If I remember correctly, this was due to driver issues, but somehow PA just handled it.
[+] [-] ShabbosGoy|8 years ago|reply
[+] [-] parrellel|8 years ago|reply
[+] [-] traitormonkey|8 years ago|reply
[deleted]
[+] [-] madez|8 years ago|reply
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.
[+] [-] madez|8 years ago|reply
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?
[+] [-] onli|8 years ago|reply
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).
[+] [-] kuschku|8 years ago|reply
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.
[+] [-] bandrami|8 years ago|reply
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.
[+] [-] ashark|8 years ago|reply
[+] [-] ro_sharp|8 years ago|reply
[+] [-] digi_owl|8 years ago|reply
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.
[+] [-] esaym|8 years ago|reply
[+] [-] esaym|8 years ago|reply
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.
[+] [-] sprash|8 years ago|reply
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.
[+] [-] dsr_|8 years ago|reply
[+] [-] jancsika|8 years ago|reply
Does anybody know if there's a similar such document for ALSA similarly written by someone who isn't an ALSA insider?
[+] [-] dijit|8 years ago|reply
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.
[+] [-] SwellJoe|8 years ago|reply
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)...
[+] [-] jlgaddis|8 years ago|reply
[0]: https://blogs.gnome.org/uraeus/2017/09/19/launching-pipewire...
[+] [-] digi_owl|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] pbhjpbhj|8 years ago|reply
>"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!
[+] [-] drewg123|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] kutkloon7|8 years ago|reply
From the sentiment here I get the feeling that it might stop working any moment.
[+] [-] shiftoutbox|8 years ago|reply
[deleted]
[+] [-] moonbug22|8 years ago|reply