1. 37
  1. 14

    PulseAudio turned out unusable wherever low latency is involved.

    I am feeling optimistic about PipeWire, as it is meant to be able to replace JACK for pro audio. Maybe there is hope for Linux audio.

    1. 12

      May I ask where your optimism comes from?

      Personally, I’m jaded: for every task a computer could have, we seem to be in a cycle where barely anything works for 5 years, interspersed with 2 years of almost-stable, before it gets ripped out and the cycle repeats¹.

      It also boggles my mind that people keep writing new software in memory-unsafe languages. I’m super uninterested in that.

      ¹ Usually with additional limitation built upon some desired fictional, perfectly spherical user.

      1. 14

        Working audio was the thing that made me switch from Linux to FreeBSD back around 2002. On FreeBSD 4.x, I had a sysctl that I could use to set the number of vchans. I then got a /dev/dsp.1, /dev/dsp.2 and so on up to the number of vchans and could point applications at them (generally, I pointed the KDE and GNOME sound daemons at 1 and 2, xmms at 3, and left the raw /dev/dsp for whatever I ran in the foreground that didn’t use a userspace sound deamon). It was a bit clunky to configure, but in FreeBSD 5 that all became transparent and so multiple things could open /dev/dsp and sound Just Worked with low-latency in-kernel mixing.

        At the same time, Linux was going through a painful transition from OSS to ALSA. Upstream OSS went proprietary, so FreeBSD forked the last BSDL version and maintained feature parity with the proprietary ones, Linux implemented an incompatible thing and told everyone to switch to it. ALSA could do sound mixing, but only if your hardware supported it (though not through the OSS compatibility layer). I had a SoundBlaster Live! but the drivers were too flaky to use it and my motherboard on-board audio controller didn’t do hardware mixing, so only one thing could play audio. KDE and GNOME both came with their own sound daemons, but I had a choice of KDE or GNOME things being able to play sound. XMMS learned to speak ALSA, but didn’t learn to speak the protocols for either of the GNOME or KDE sound daemons, so I had a choice of music, notifications from my (KDE) chat app, or from my (GNOME) mail client, but not more than one of them on Linux.

        Fast-forward a decade or so and everyone I knew on Linux was complaining about PulseAudio. Meanwhile, my FreeBSD media center box was happily driving my 5.1 speaker system from anything that could produce 5.1-channel audio (e.g. VLC playing DVDs).

        Eventually, PulseAudio got to the state were it mostly worked for most users and so now Linux distros are justifying their existence by replacing it.

        I honestly have no idea why people choose to use Linux at this point.

        1. 4

          Eventually, PulseAudio got to the state were it mostly worked for most users

          The most annoying thing is while pulseaudio mostly works (which explicitly means it doesn’t actually work - i still despise it since it messed up my mic randomly and can’t play sound from two users at once, like come on)… ALSA is actually pretty decent now and its dmix plugin solves the problem you (and I) used to have.

          As soon as something starts mostly working, Linux wants to replace it. And by the time the replacement is mostly working, the last generation is actually pretty good… but since it is two generations ago now the culture is you’re some kind of tech-hating dinosaur who refuses to embrace new things in the eyes of half the people.

          Drives me nuts. And it happens all over the linux ecosystem.

          1. 2

            I had a similar experience. I was getting frustrated with the issues that Linux had only be able to play sound from one source.

            I tried out FreeBSD and for a long time, that was my driver up until I got a MacBook for college. Still use FreeBSD and OpenBSD in a few places to this day. I haven’t tried a lot of advanced scenarios but I’ve got a new laptop on order that I’m going to throw FreeBSD or OpenBSD on as the primary driver.

          2. 10

            It also boggles my mind that people keep writing new software in memory-unsafe languages.

            The primary driver behind multimedia for Linux is in embedded systems, specifically in the consumer and automotive infotainment space. Especially back in 2016 when PipeWire was started, the intersection of “languages that are adequate for real-time processing” and “languages with reliable ports for relevant architectures” was practically zero.

            Even today, getting internal buy-in for e.g. Rust in applications like these is extremely difficult. Not just because of current architecture support, but also because of the shape of future applications. When the next i.MX-series application processor shows up, it’s bound to have a GCC port available – NXP will sponsor it, and if you really need that and have the money, they’ll offer support for it, too. Whether that’ll be true for Rust is anyone’s guess – it’s anyone’s guess if NXP will even publish enough documentation to make a good quality port feasible in the first place. A multimedia daemon that may or may not run on the hardware you want, and where support hinges on whether someone will take a chunk of their spare time to port a pretty massive toolchain, is dead in the water as far as this part of the embedded field is concerned.

            I’m not saying it’s right, it’s just how it is. A sizeable percentage of the vendors in this space will gladly sell you devices that break just about every bit of security-related best practice out there. Memory safety is so low on their priority list that they probably run out of paper before they get to putting it in writing. What matters to them is reliable support for commodity hardware via commoditised development teams (because they outsource development to the cheapest available source, almost nobody develops things in house in these fields today). Rust’s story for these things is hardly the best.

            Edit: also, not parent poster but I share their optimism:

            May I ask where your optimism comes from?

            You want to put this in the context of Linux. After PulseAudio anything in this space is bound to generate some optimism. It’s hard to make it worse :-D.

            1. 8

              May I ask where your optimism comes from?

              Lennart is not involved this time.

              1. 1

                i.MX-series application processor

                uh, it’s just Arm? The Librem 5 famously uses an i.MX8, which is just aarch64, of course Rust just works there. Even more car-specific SoCs these days are aarch64.

                With “deeply” embedded stuff you could argue that C lets you support any weird custom microcontroller, sure. (But, like, avoid those as much as possible anyway?)

                But for “Unix class” application processors – where Linux+PipeWire runs – there are basically no options that aren’t supported by Rust/LLVM. No one is building infotainment systems on Itanium, Alpha, or m68k! :D

                1. 1

                  Ugh, sorry, I either didn’t get a notification 34 hours ago or I missed it…

                  i.MX was definitely not the best example because, indeed, it’s “just” ARM, although the story is more complicated than that (see below). That being said, virtually all the platforms that were relevant in these spaces back when PipeWire was started, and even today, are (at best) Tier 2 (only aarch64-unknown-linux-gnu is Tier 1) and nobody is going to put that in a box and sell it in a field where product recalls are a thing. And, of course, there is always the question of compiler support for various extensions, and sometimes even for new architectures, albeit certainly not an 1990s level.

                  But please keep in mind the rest of my comment as well. It’s not just about whether there exists a compiler that treats a platform as a first-class citizen.

                  Least cynically, getting commercial support for a C toolchain is not a problem. The “golden” (quotes because the actual material is somewhat, uh, browner than gold…) standard you work against is a vendor-supplied BSP. (Edit: “BSP” is used somewhat more loosely nowadays – you generally get it in the form of a Yocto-based distro, which – among other things – will build its own toolchain). The hardware vendor will usually give you a vanilla GCC with some patches. Major Linux consultancies (that’s very common in the automotive and consumer space) will usually give you a BSP based on the one that the vendor supplies, and some of them do give you a toolchain with all sorts of bells and whistles (some even give you a full IDE, with some useful goodies, like a compiler that won’t make you hate your life), in the form of some $MajorVendor Embedded Linux. Either way you get commercial support.

                  More cynically, but equally important: there are Android-enabled platforms out there that are horrifying to use – think you need a Ubuntu 12.04 machine to build the toolchain, the application-packaging script has to run as root out of /opt/VendorToolchain/user_app/, and the driver code does synchronisation by disabling all IRQs and sleeping for hundreds of milliseconds. They’re popular not on technical grounds – indeed, if that were all that mattered, you’d have to pour gasoline on it and set it on fire – but because they’re Android-based, and Android has Google behind it. That means a big vendor will be behind it ten years from now, that there are hundreds of outsourcing shops out there willing to jump in if the outsourcing shop you’re working with today goes under or wants to charge you 10% more for your next project and so on.

                  It’s not a pleasant thing to admit but I think you’ll only see Rust being used in these fields when a) a few major vendors will start using it, in a very public manner, in a well-hyped function (that’s sort of starting to happen) and b) it’ll be very easy to find Rust development services in one of the “traditional” outsourcing destinations, like SE Asia or Eastern Europe, because nobody is going to pay US/Western Europe salaries for infotainment systems.

                  (Note: before yelling “racism” at me, please consider that I’m speaking from my experience of working in one of these traditional outsourcing destinations ;-). )

              2. 2

                It also boggles my mind that people keep writing new software in memory-unsafe languages. I’m super uninterested in that.

                There isn’t currently a good alternative. Software like Pipewire needs to work in very low-latency space- and memory-constrained settings (garbage-collected languages are out) and needs to be extremely portable (Rust is out).

              3. 11

                (I originally deleted this comment because it ended up a bit too resentful and I don’t think it’s fair. “This comment was deleted by its original author” looked equally unfair though :-).

                Let me try again, focusing only on the good parts: I have pretty high hopes for PipeWire because it’s written by people with a great deal of understanding and expertise in terms of multimedia and real-life applications. Wim Taymans, the original developer behind the project, is one of the people who started gstreamer back in the day. I also have high hopes about its early roll-out: PipeWire is already pretty old now, and works remarkably well out of the box, but not everybody is rushing to roll it out by default – a far more responsible approach than what happened, uh, the last time).

              4. 14

                The Linux desktop community amazes me.

                “Linux audio is and always has been awful.”

                (Smart, dedicated people work YEARS to fix this)

                Pipewire Team: “We present to you: NON CRAPPY LINUX AUDIO! YAYYY!!!”

                Linux desktop community: “Linux audio is and always has been awful.”

                Me: (facepalm)

                More seriously, I’m running it on an Arch install and I love it. It works great for me thus far and I love the JACK-like capabilities built right in.

                IMO PipeWire represents that kind of innovation I love to see Linux spearheading.

                1. 11

                  I am running this locally since a few weeks. It’s pretty neat (reroute any audio from any app to any plugin and back) and still has some bugs. The tradeoff is having to restart it sometimes when things are too broken, which is fine for me.

                  I wrote a little bit about my experience with it so far recently: https://papill0n.org/blog.html#id:pipewire-works

                  1. 2

                    Thanks for posting your review! It encourages me to give pipewire a spin :)

                  2. 6

                    Am I the only person who’s had no problems with PulseAudio? The only thing I had to work around was a dumb hardware bug.

                    1. 7

                      Today? No. Back when it became the default on Fedora, Ubuntu & friends, yeah, you’d have been the only one. It needed years before it was reasonably reliable, not the least because the way upstream treated bug reports – and the wider open source community in general – was abysmal.

                      1. 3

                        Same. Bluetooth devices were flaky, Steam games were occasionally filled with static. It was so hit and miss.

                        Today it works really well for me. I don’t have a need for super low latency, so I haven’t tried Jack, but for everything else it works pretty well. Even bluetooth devices.

                        I was afraid it was going to turn into another systemd, but I think it’s faired better. It’s far better than esound and arts for sure (for those old enough to remember the really old sound server concepts).

                        1. 4

                          PulseAudio improved enormously after project leadership changed. A responsible approach to development with no abrasiveness towards users regardless of tech-literacy runs circles around any ego-driven process, no matter how much technical expertise is there.

                          As far as PulseAudio is concerned, it certainly didn’t help that for all the Linux-related technical expertise there was in the beginning, knowledge of practical multimedia applications was very obviously not there, so many dubious choices, at every level, were framed as innovations or useful design trade-offs simply because nobody understood the real-life implications. That is, nobody who really cared, trying to report a bug or submit a patch was generally enough to drive people with good intentions away.

                      2. 1

                        Until I uninstalled it, it would regularly make my sound device disappear randomly. Other times it would mute one ear but not the other upon insertion of headphones. Getting rid of it was one of the best moves I’ve ever made when it comes to software on my laptop.

                        I believe you that you haven’t run into issues, but I chalk it down to just a lot of luck.

                        1. 1

                          I was thinking the same thing. I’ve been on Linux 100% of the time for the last 5 years (off and on before that). No problems with PulseAudio.

                        2. 3

                          As long as it is something that I do not need to uninstall, like PulseAudio, to get working sound it’s fine I guess.

                          1. 1

                            I’ll have to finally give this a try.

                            I am not after pro-audio but I do have an audio interface for mic’d up zoom calls etc, and the latency on it is bad when I monitor from my PC rather than directly from the interface itself. This isn’t a massive problem but I’d quite like to route the audio through my laptop so I can use my bluetooth headphones…!

                            The only solution I can see is some pulse-jack hybrid which scares me…

                            1. 1

                              I will be excited when someone gets a good port of *BSD style OSS going. Everything else is busywork