You seem to exist in a fictional universe where pulseaudio "got good" and doesn't suck. All these years later I have never seen that be the case. I think a much more likely explanation is that desktop Linux is less common since the rise of OS X in the "Unix-like developer machine" market so there are now fewer people noticing it sucks.
I believe the universe I exist in is real, but how would I know for sure?
Anyway, I haven't had to google about a pulseaudio problem in at least a few years. I've been using Linux as my primary desktop OS since 1995. I've hated Linux audio for most of that time, and I've broken it in every possible way. But, today, my Fedora system has sound that Just Works. I don't know how it Just Works (though I know it's pulseaudio), because I haven't had to learn...because it Just Works. It works for Steam games, it works for browser audio, it works for system notifications, it works for movies, it even works for audio and music software. It's pretty weird.
Anyway, from what I can tell, the bugs, misfeatures, poorly thought out implementation, etc. all got worked out somewhere along the way. It took a long time. But, it did get fixed.
Have you actually used it in the past couple of years?
The main problem with PulseAudio is that it "just works" for the majority of users, but then it fails randomly, unpredictably, unrepeatably and with no indication of what is going wrong, and most of the time you get a "uh, works for me". This is a kind of experience that I was used to expect in Windows, not in Linux.
Just two more random examples:
RPi 3, audio would hang randomly when opening a new process using audio from another using audio. The solution would be to either play an audio sample from the command line to unclog the audio system, or uninstall PulseAudio.
Ubuntu 16.04. Rewinding the video while using mplayer could cause the audio to play at a faster rate. Again uninstalling PulseAudio would solve the problem.
yeah, future version of PA should had one command 'uninstall'; all linux users would use PA with joy now.
I often feared PA, and something in ALSA (I almost know zero about linux audio stack) made it a zero effort / 99% working thing that matched what I want for audio, that is a no sweat thing that just push sound. I can live without multi room networked audio, but having local audio crash randomly is too much a PITA. Feels like having lisp macros on top of VBA.
That said I wish we could find a better solution. Something between ALSA and PA. Also PA demands quality driver, IIRC Lennard told he cannot get blamed for that, it's a bit like GPUs in a way; and I wish we'd have open hardware audio chip that were simple and not lying.
I don't know why you're downvoted.
One thing though: if Lennard blames the drivers, he should at least implement some fallback mechanism to use when a feature is unavailable or can't be relied on to work reliably. Honestly, if with the same drivers ALSA works fine and PA doesn't, it's hard to blame the drivers.
I think it's a bit more subtle than that. PA asks more from the hardware to do more than ALSA (sampling capabilities, and latency), if the drivers report fake numbers to ALSA it might work fine for its limited use case, while it fucks PA logic entirely.
That said a default fallback would be so good. I can't stop thinking that LP writes things for his own world and leave it there when he's "satisfied" with it; even if it means shit for the rest. Which means the issue is that he shouldn't be in charge of socially impactful components.
> I can't stop thinking that LP writes things for his own world and leave it there when he's "satisfied" with it; even if it means shit for the rest. Which means the issue is that he shouldn't be in charge of socially impactful components.
Unless you have examples of solid patches fixing these kind of problems that he rejected, this is a significantly unfair statement.
Fair point, he's not the only coder in his projects, and maybe it's unfair social response that influence me, but his projects always rub people the wrong way, even though they carry brilliant useful ideas. Also if the overall design impede fixing without too much hassle ..
He seems to suffer from massive ego. He always assumes that if his stuff is failing, it’s somehow someone else’s fault, and refuses to acknowledge fault even when evidence is presented.
At least that’s what’s been apparent to me from the things that I’ve read by him and about him.
He often has a lot of good points, but it's not enough when assuming a pivotal role in society. You cannot just be right 60% of the time, because 40% people leftover is far too much. It's saddenning for instance, PA had valueable goals, but if the design assumes hardware that doesn't exist (exagerating) then it's not a good fit for a standard audio stack.
And I'm not sure it's really ego.. I'd rate him at about 0.07geohots.
I did try to use it and discovered that it's impossible to configure mpd to run as a system service and be able to play sound while also allowing desktop applications to play sound. I forget all the details, but the way I figured out how to get sound to do what I wanted was to enable alsa dmix and to pipe everything possible through dmix, using pulseaudio only for the one or two essential apps that insist on it.
Funny, I just did that yesterday. I was reconfiguring my mpd server and I saw it was configured to use alsa (which, incidentally broke my sound occasionally). I set it up to use Pulseaudio and now I can listen to mpd server while listening to deezer.com that runs through browser while making a skype call on the same machine (not that I'd want to do it, anyway).
Exactly. Does it support redirecting audio streams to another machine on the same network? That's a vital feature in our hackspace, where everyone can send audio to the room speakers via PA, and it's also used extensively in my living room (where the speakers are connected to the home server).
I don't know, but sending audio over a network sounds like the sort of use case that requires a sound server. Playing sound locally doesn't. Although, as I said elsewhere, I have mpd stream to icecast for playing my audio remotely so, in my case, I don't need pulseaudio for this: I imagine you could configure a similar setup where anyone on the local network can register with icecast as a "radio station" znd stream sound that way.
A workflow that enables network transparency by using a tool for radio stations might work for music, but not for anything with latency requirements. Imagine playing any video game with even a 100ms audio delay.
That's something that really bothers me about pulse: it looks like it should have a nice unixy design and work well, but actually using it is, in my experience, a complete potshot.
For me the important advance was redirecting an audio stream to a different device on my machine, as I wanted to happen when I plugged in my USB headset. Currently that works more smoothly on Linux for me than Windows.
When you log out of your desktop session, does mpd continue playing? I have mpd setup to stream via icecast so I can listen to my music remotely and the issue I was having was that when I logged out of my desktop, the music would stop playing because the sound server was tied to my desktop session.
I believe personal experience is anecdotal at best and not "the universe". My anecdotal experience with pulseaudio is that it simply does not like my setup (internal sound card + 4 external usb card + occasional hdmi sound transport) and having an occasional pop or crack on a 10kW PA system is not desirable.
I've read a pulseaudio guru post explaining that when you know what you are doing you can work out a pulseaudio config that reduce pulseaudio latency issues, real time resampling, drop outs and high cpu usage. Just don't use the default config.
internal sound card + 4 external usb card + occasional hdmi sound transport) and having an occasional pop or crack on a 10kW PA system is not desirable.
This is a common issue. It happens on Windows and Mac, as well. Am I to understand you don't experience it with some other way of handling sound (e.g. not using PulseAudio)? Are all of them being driven by the same program?
I DJ, and have used multiple independent interfaces in the past; there were frequently pops and warbles as the various timing crystals in the various interfaces fell out of sync and were forced back into sync by the software. It happened on both Windows and Linux (though it was slightly less pronounced on Linux, and I never figured out why). JACK might be the best way to deal with that problem on Linux, though I never tried it (I just switched to a dedicated DJ controller with multiple outs and headphone output).
But, it's a common enough problem that most DJ software has something about the problem in their FAQ.
As far as I know, Pulseaudio still hasn't fixed the four and a half year old bug which causes Bluetooth audio to get more and more out of sync until you reconnect: https://bugs.freedesktop.org/show_bug.cgi?id=58746
The one procedure I use to fix non-working sound on Linux consists of 1 - look at the package manager for pulse-audio; 2 - Uninstall it.
Works every single time. last time I did it was around March. (I still don't know how it creeps back into my computers.)
Last time pulse was creating problems for me I decided that since I was now writing an application that links to the sound system, let's stop linking to low level functions and use pulse abstractions that some people claim to be better.
Turns out that the pulse "abstractions" are basically verbatim copies of alsa. Just with some added badly documented options. Some with very descriptive names, other with cryptic ones, but whatever, no option seems to do exactly what its name implies. Besides, pulse abstracts away most of the flexibility of the sound hardware, so you can't use it, and well, every time I tried running something with it, I got an assertion failure on pulse code... Always with some completely non-descriptive description.
What were your problems exactly? In my case I used Linux full time from late 2012 to early 2014 and during that time I haven't had a single problem related to it, all while running bleeding edge Archlinux. The only issue was with bluetooth headphones but I'm pretty sure it was more with BlueZ being a pile of garbage than Pulseaudio being bad, given that BlueZ was giving me problems with all sorts of other (non sound) peripherals as well.
Mostly the same issues as BeetleB. It purports to pump audio samples. It does not. Another moving piece in between your app and ALSA, which seems to break down inexplicably when the crap that it's abstracting "just works" with zero configuration. Many times the solution to an audio problem on linux is to get rid of pulse. Still.
Also had issues with bluetooth, as you seem to have. I will permit the idea that this is possibly unrelated (bluez is garbage, yes), but bluetooth audio was working for me previously, and only broke when pulse entered the picture.
FWIW from an API perspective I still think OSS seems better than ALSA... Linux audio seems to be a repeated case of people confusing interface with implementation, and the interface only ever gets more complex.
The amusing part is that FreeBSD is still on OSS, and it "just works" - and they let multiple apps play audio at the same time simply by opening the same device. It's been that way... I don't even remember how long, but I think it was already there 15 years ago?
And OpenBSD introduced its own userspace daemon for mixing multiple audio streams together. The by-then already existing libsndio would then just default to opening the socket provided by that daemon. So, the change was transparent to applications (no code changes, they already used libsndio) and users (no configuration, at least for people running defaults) and didn't cause years of grief, agony, churn, hatred, and shitstorm.
Of course you can still trivially disable the daemon and you lose software mixing & resampling, but things that work within these limits will run ok. But there really shouldn't ever be need to disable it, it just works.
I tried installing it a few months ago, and... could not get any sound. Similar experience several years ago. I'm sure I could Google and fix, but for me, it did not "just work".
Don't get me wrong. For years, ALSA was a pain. But in the last 10 years, ALSA has always "just worked" for me. I think the only time I had to fiddle with ALSA in the last decade was to get the mic on a headset to work.
For me, "Just Works" includes me not having to install it at all, not it being easy to set-up on LFS. Pulseaudio is pre-installed on Fedora, Ubuntu, etc.
ALSA is part of the kernel, it's likely been pre-installed in every Linux you have ever run. It's not a mark against it that you choose to install distros developed to use pulseaudio.
I've occasionally seen issues on one of my machines where applications would send out garbled audio until I killed the PulseAudio process and restarted the application (the latter was insufficient alone; PA had to be killed). Hasn't happened lately, though, and it might've had more to do with the application.
I use Slackware, which tends to be more conservative about these things; the fact that PA is now the default in Slackware is a good indicator of PA having overcome its growing pains.
I have a feeling if PA was really as broken as it was once upon a time, Bluetooth audio would've been sacrificed in favor of a more stable and reliable system.
Additionally, I somewhat doubt BlueZ would've made PA such a hard dependency if they weren't reasonably sure that it's stable enough for primetime.
Are you actually using PulseAudio? Having run Arch (well, Parabola) since 2011, I haven't had any problems with PulseAudio... because I've never installed PulseAudio. Actually, I did have a problem with Wine and lib32-libpulse lagging slightly behind the video (where it's only a fraction of a second off, but enough that it doesn't feel like the words match the faces); and then I figured out how to get Wine to use ALSA, just like everything else.
I was one of those developers with an OS X machine who decided to buy a Thinkpad and throw Ubuntu on it. pulseaudio worked out of the box for me and I definitely preferred it over the stunted OS X audio mixer that doesn't even let you define per-application audio.
The MacOS mixer is pretty much the epitome of "just works" even though I agree with you that it doesn't let you control levels per application.
However I've been using the MacOS sound system (not just the mixer) for many years through many devices (mics, external dacs, HDMI transports, DP etc) and it has always worked without any problems.
I don't have much personal experience, but I /often/ hear about OSX users very wary of updating MacOS because of issues with sound equipment. This goes back to Classic. It may have gone away in the past 3-5 years, but the stigma is still there.
Never had issues with PulseAudio in the recent times. I use Linux for all my desktop needs, including gaming. Of course if you have specific audio needs that require more realtime processing, you can for example use Jack.
Maybe you really do live in a different universe, because my audio sounds good and I legitimately can't remember the last time I had to worry about it. It's been years, and now for the first time on Desktop Linux I can connect a Bluetooth or USB audio device without wondering if I could actually coax my software into using it.
You mean "macOS". But I don't see the relevance. Is it because the name no longer contains an "x" character? The X in OS X had no relation to unix, it was because it was the successor to MacOS 9 (and in fact the full name was originally Mac OS X).
We are using it for develoment but it's considerably more work to setup the develoment environment than installing a Linux distribution with everything we need available by default or a command away. Also in El Capitan the root user is disabled by default.
- You can't log into the UI as root (by default), and that is a good thing.
- SEP prevents you (or any random script/software/installer you run) from meddling with system files and that is a good thing too, no different from sensible SELinux or AppArmor policies.
Whether or not it's Unix-like has nothing to do with the name. I was taking issue with the fact that you were suggesting the name change indicated that it's less Unix-like.
That said, macOS is just as Unix-like as it's ever been. As lloeki said, it's actually closer to BSD than Linux, which may explain some of your gripes.
As for the root user, it's been disabled by default since Mac OS X first came out. Being able to log in as root is considered a security risk, and there's no need for it. If you want root access, use sudo.
What all are you lumping into dev environment setup? For many years most projects have only needed two steps (CLI toolchain install, Homebrew) plus the project specific setup.
Different versions of perl, node, mariadb, apache. I am using Homebrew as well, was using Macports but it pulls too many dependencies. You still need to install Xcode for which you need an appstore account. On Linux you're pretty much done after you install the OS, or maybe you might need to apt install build-essential.
Perl allows multiple installations using plenv or perlbrew. You activate one of those or the system Perl. For the rest we just need one version - the one that runs in the production machines.
I personally hope Linux application developers support PipeWire as it becomes available so that the usability issues around low-latency audio in Linux can be sorted out (i.e. it works out of the box):
I haven't used PulseAudio until very recently when Firefox started requiring it for audio (chrome/chromium still support plain ALSA), that said I haven't come across any problem, what should I be looking out for ?
- a while ago pa got audio routing wrong on a new/obscure laptop, wrong audio routing as in - speakers would not turn off if you plug in headphones. That eventually got fixed with dnf upgrade and no effort on my part;
- on ultrabook, pa sucks noticeable amount of battery by waking up 100 times a second (while no audio is being played). Something akin to what this poor chap is describing:
Nothing really, it's fine for nearly everything and just tends to get on with the job.
The only bug that's affected me in the last couple of years was that the default volume on USB headsets was always set way too low. Pavucontrol helped sort it out
The only problem I've had recently is that I can't seem to split up different ports on the same card (optical home theatre/soundbar for music, desktop stereo for everything else), but that's not something I was able to do with ALSA anyway.
Something to do with opening the card in different profiles I think.
