PipeWire: The Linux audio/video bus [LWN.net]

PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 4:32 UTC (Wed) by darwi (subscriber, #131202) [Link] (12 responses)

> Nobody liked Pulseaudio, but I hope the transition here goes a whole lot smoother than the ALSA to Pulseaudio one did.

I had no space left in the article to further expand on this, so I'll write it here: breaking users audio was not always PulseAudio's fault. It was the first heavy user of a certain class of ALSA APIs like audio buffer rewinding; e.g., snd_pcm_rewind() and friends. The proprietary Adobe flash plugin, prevalent back then, also caused its own unique set of problems.

Nonetheless, yes, PulseAudio (and especially its glitch-free support) was pushed too early on users. "I'll break your audio", the constant tongue-in-cheek remark by PulseAudio's lead developer back then, did not also always help. Humility, and some sympathy for users with broken audio setups, were definitely lacking.

The good news is that the community as a whole learned a lot from the ALSA→PulseAudio transition fiasco. Remember that everyone is also more than a decade older now… Everyone is (hopefully) a little-bit wiser.

By the way, the PipeWire developers are keenly aware of the previous audio API transition issues. This was discussed at length in the PipeWire 2018 hackfest: an adults-in-the-room orderly PulseAudio→PipeWire transition was planned early-on. I'm personally optimistic :) [Famous last words?]

PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 4:48 UTC (Wed) by Subsentient (subscriber, #142918) [Link] (2 responses)

>Remember that everyone is also more than a decade older now… Everyone is (hopefully) a little-bit wiser.

You think so?

PipeWire: The Linux audio/video bus

Posted Mar 4, 2021 6:12 UTC (Thu) by darwi (subscriber, #131202) [Link]

> You think so?

Posting an empty comment that is just a link to a GIF meme does not contribute to a healthy discussion. Assuming that you were posting in good faith, then the answer is yes, I do (based on interactions with a lot of active developers across the stack.)

PipeWire: The Linux audio/video bus

Posted Mar 11, 2021 10:21 UTC (Thu) by oldtomas (guest, #72579) [Link]

Besides, your link wants me to "do" some javascript to see the gif. My browser was too lazy, so I didn't see anything. Perhaps I'm glad I didn't :-P

PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 13:44 UTC (Wed) by pizza (subscriber, #46) [Link] (2 responses)

> The good news is that the community as a whole learned a lot from the ALSA→PulseAudio transition fiasco. Remember that everyone is also more than a decade older now

It's probably more accurate to say that a _huge_ number of ALSA and application[+library] bugs were uncovered and fixed during the early PA days, and that work continues to pay dividends, making future migrations much easier.

(The main technical reason for the ease of the PA->PW migration is that PA and PW both provide ALSA plugins so that software natively using the ALSA API continues to JustWork, and of course PW provides a drop-in PA library replacement..)

PipeWire: The Linux audio/video bus

Posted Mar 4, 2021 4:14 UTC (Thu) by darwi (subscriber, #131202) [Link] (1 responses)

> It's probably more accurate to say that a _huge_ number of ALSA and application[+library] bugs were uncovered and fixed during the early PA days, and that work continues to pay dividends, making future migrations much easier.

Yes, of course. I thought this was implied. I meant also "wiser" in the technical sense.

> (The main technical reason for the ease of the PA->PW migration is that PA and PW both provide ALSA plugins so that software natively using the ALSA API continues to JustWork, and of course PW provides a drop-in PA library replacement..)

It's not only about that.

Anyone can implement compatibility layers; e.g., roaraudio reimplements the PulseAudio APIs. On the ALSA compatability side, ALSA plugins are actually the simplest part of the equation: it's usually a single C file with some hundred lines of code + a 10-line configuration file.

As discussed in the article, how PipeWire is internally designed is actually what helps a lot. Don't underestimate how a proper initial rigorous design makes things much smoother at the later adoption and transition stages of any software project. A proper design makes everything "fit into place".

PipeWire design and code is semantically simpler than PulseAudio; in part, because everyone got wiser. Anyone who has worked inside the PulseAudio code base for a while will know what I mean here ;)

PipeWire: The Linux audio/video bus

Posted Mar 5, 2021 14:22 UTC (Fri) by ecree (guest, #95790) [Link]

> PipeWire design and code is semantically simpler than PulseAudio; in part, because everyone got wiser.

Sounds like PipeWire may be an example of third-system effect. A good sign.

PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 16:55 UTC (Wed) by HenrikH (subscriber, #31152) [Link] (1 responses)

> Nonetheless, yes, PulseAudio (and especially its glitch-free support) was pushed too early on users

I'll beg to differ, the only reason that the ALSA drivers where ultimately fixed, that PA became usable and that software started to use PA was that it was pushed out to all users as early as it was. Had it not been done this way then PA would be closer to where Wayland is today and PipeWire would have been decades away in the future.

The real QA for any software projects only comes on the day that you get it pushed to end users, it doesn't matter how much internal QA you have done.

PipeWire: The Linux audio/video bus

Posted Mar 4, 2021 21:26 UTC (Thu) by marcH (subscriber, #57642) [Link]

> The real QA for any software projects only comes on the day that you get it pushed to end users, it doesn't matter how much internal QA you have done.

There's always an infinite supply of bugs. If you ever run out of them, just test harder and you will get more. It's a continuum.

Once you ran out of sensible use cases, pass it on to a security team.

PipeWire: The Linux audio/video bus

Posted Mar 5, 2021 7:00 UTC (Fri) by WolfWings (subscriber, #56790) [Link] (3 responses)

I'll be honest, PulseAudio headaches kept being so bad and responses soured me so hard on the platform that I'm still using native ALSA instead with PulseAudio not even installed at all on my systems.

They REALLY burned bridges with their attitude and flippant responses in a way few understand, and with many ALSA sound card drivers supporting multiple programs attaching at the same time the main 'requirement' for PulseAudio has become moot at this point for simple laptop or desktop audio use.

PipeWire: The Linux audio/video bus

Posted Mar 6, 2021 1:52 UTC (Sat) by BirAdam (guest, #132170) [Link] (2 responses)

I actually use OSS4. I was mad enough with ALSA’s release, and then Pulse came out and OSS had been fixed in the mean time so I went back.

PipeWire: The Linux audio/video bus

Posted Mar 6, 2021 1:58 UTC (Sat) by pabs (subscriber, #43278) [Link] (1 responses)

Is OSS4 still developed?

PipeWire: The Linux audio/video bus

Posted Mar 6, 2021 5:22 UTC (Sat) by BirAdam (guest, #132170) [Link]

Indeed. Yes.

http://opensound.com/

PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 8:52 UTC (Wed) by chris_se (subscriber, #99706) [Link] (19 responses)

Nobody liked Pulseaudio

I'd like to disagree here. I don't love PulseAudio, but with PulseAudio it was the first time I actually got audio working somewhat reliably on Linux. Previously audio was always a real pain, and it never worked reliably at all. I remember bare OSS, bare ALSA, and even such things as aRts. I always spent a long time trying to get it to work somehow, and then some application came along that didn't work with the setup and I had to figure stuff out again.

Note that I'm the opposite of an audiophile, my only requirements are that the sound comes out of the device I want it to, that I can dynamically plug in a head set, that I can adjust the volume, there are no cracks due to buffer underruns, that multiple applications can output audio at the same time, and that I can change settings easily via GUI. I don't think these requirements are particularly onerous (I don't even care about stereo audio, I'd be more than happy with mono), but pre PulseAudio I was never even able to achieve even these basic things.

Once PulseAudio came, the first couple of releases it wasn't great, but no worse than my prior experience -- but after a while it actually became reliable. It was the first time I could actually use a Bluetooth headset. (I experimented back when support first appeared in the audio stack before PulseAudio, and that barely worked at all.) Sure, some things still didn't work quite as well as I'd hoped, and there are some issues, but for me PulseAudio was a major improvement compared to everything that came before it. I think PulseAudio has a reputation that is worse than it deserves by a long shot.

That said, PipeWire does sound extremely promising, and I'm very excited to try it out at some point when I can find some time, because I do sometimes bump into some of the warts of PulseAudio.

PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 13:14 UTC (Wed) by ms-tg (subscriber, #89231) [Link] (17 responses)

I wonder how we are culturally at the point that it seems worth the time to write a comment simply to agree that I shared this experience.

PulseAudio was a huge improvement for me over what came before. Am I misremembering, or wasn’t the prior state that we would have apps crash with “could not open ...” if two apps were trying to make sound at once?

PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 13:26 UTC (Wed) by pizza (subscriber, #46) [Link]

> PulseAudio was a huge improvement for me over what came before. Am I misremembering, or wasn’t the prior state that we would have apps crash with “could not open ...” if two apps were trying to make sound at once?

Followed by trying to figure out exactly what application was holding the sound card open. Or zombified sound mixing daemon, of which there were several.

(Unless you were one of the fortunate few to have a sound card that could natively handle multiple simultaneous streams!)

Still, even in its early days, PA was a _huge_ net improvement, and most of the issues that folks attributed to PA were really bugs in the underlying device drivers or applications themselves. (I recall the flash plugin being one of the worst offenders..)

(Something similar played out with NetworkManager/wpa_supplicant and wifi devices that didn't implement the WEXT APIs consistently, and/or applications that were written expecting the quirks of a single driver to apply everywhere)

PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 15:47 UTC (Wed) by chris_se (subscriber, #99706) [Link] (7 responses)

> Am I misremembering, or wasn’t the prior state that we would have apps crash with “could not open ...” if two apps were trying to make sound at once?

All of the other "sound servers", such as aRts and ESD, were created just for this reason. For programs that weren't compatible with them (basically anything not KDE / not GNOME) you had to start them with a wrapper that used a LD_PRELOAD library to hijack the system calls to open the ALSA/OSS devices, and reroute that through aRts/ESD -- but that didn't work with all software, so you had to kill the sound servers sometimes to use some applications. And then others using the sound server would misbehave. And don't get me started with Suspend-to-RAM, which typically killed any application that was currently outputting audio when closing your laptop lid...

I do remember ALSA having native software mixing, but from what I recall it required all applications to use the same sample rate for their audio, which of course was often not really the case. (Maybe that's changed in the mean time?) And you had to configure it manually in your ~/.asoundrc. Also, I don't know exact time this was added, but I remember seeing ALSA software mixing for the first time when PulseAudio was already a thing, so maybe it came way too late. Or at the very least it wasn't advertised very well, because I didn't read about it before I was already switching to PulseAudio.

PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 19:32 UTC (Wed) by dezgeg (subscriber, #92243) [Link] (5 responses)

At least my personal recollection is that there was a period where ALSA software mixing (without any tweaking of .asoundrc or anything on most distros) was working very well, better than PulseAudio - as in, many audio problems could be solved by a "killall pulseaudio" (I do not remember if root was required for this or not).

However this was long time (years) ago, definitely before me owning any USB or Bluetooth exclusive audio devices. I do not even remember when "killall pulseaudio" last solved anything And regardless of that being able to adjust sound levels per-application with PA has been very useful (lack of it is not show stopper but just very nice to have).

PipeWire: The Linux audio/video bus

Posted Mar 4, 2021 4:52 UTC (Thu) by jeltz (guest, #88600) [Link] (2 responses)

I still have to solve audio problems by killing PuleAudio (last time I did it was about 2 weeks ago), and as far as I know it coul always be done without superuser privileges. I am one of the minority who never have experienced PulseAudio becoming stable, it is better than ti was when I first used it but still quite unstable.

PipeWire: The Linux audio/video bus

Posted Mar 5, 2021 0:06 UTC (Fri) by hailfinger (subscriber, #76962) [Link] (1 responses)

Killing/restarting pulseaudio (pulseaudio -k) after a suspend-to-RAM is required and sufficient to get my USB webcam microphone working again in ~90% of my suspend cycles. That's a few times per day. I didn't bother reporting that because I've seen too many pulseaudio bug reports being dismissed along the lines of "pulseaudio is never buggy, it's the fault of your driver/application/whatever".

PipeWire seems to care about not breaking existing setups and the article implies that the community is nice. I'm happy about that and look forward to testing it.

PipeWire: The Linux audio/video bus

Posted Mar 5, 2021 5:56 UTC (Fri) by zdzichu (subscriber, #17118) [Link]

Not to defend PA, but it really smells like USB microphone driver problem. It seem not to handle suspend/resume cycle (while device is opened?).
If you do not report bugs, they won't be fixed. And you will have the same problem with pipewire.

PipeWire: The Linux audio/video bus

Posted Mar 4, 2021 15:45 UTC (Thu) by sorpigal (guest, #36106) [Link] (1 responses)

For whatever it's worth I still run purely ALSA with software mixing, including things like USB audio devices (just added a new mic yesterday), multiple applications playing audio at the same time, and everything Just Works with no issues. I do have a .asoundrc, but it's pretty boilerplate and I haven't had to change it in years. The only time I have audio trouble is when I need to run a program that only supports pulse (but there's apulse for that).

The only thing I occasionally pine for is per-process volume control.

PipeWire: The Linux audio/video bus

Posted Mar 18, 2021 9:20 UTC (Thu) by mgedmin (subscriber, #34497) [Link]

Is pure ALSA able to move a playing stream from one device to another (say, internal speakers to a Bluetooth headset)?

PipeWire: The Linux audio/video bus

Posted Mar 17, 2021 10:18 UTC (Wed) by immibis (subscriber, #105511) [Link]

I am not sure how things were "back then", but ALSA today has both rate conversion and mixing plugins. If you layer those in the right order, applications can output at different rates. Whether the default configuration does this or not is a different question.

PipeWire: The Linux audio/video bus

Posted Mar 7, 2021 9:23 UTC (Sun) by jengelh (guest, #33263) [Link] (6 responses)

>Am I misremembering, or wasn’t the prior state that we would have apps crash with “could not open ...” if two apps were trying to make sound at once?

Quite the contrary. People had actual proper soundcards (me: ad1816 or cs46xx on daughterboards), and with other chips (me: ali5451 in first post-2000 laptop), there was ALSA's dmix that would do software mixing via shared memory, before moving the software mixing off to separate - and quite high latency! - daemons like PA.

PipeWire: The Linux audio/video bus

Posted Mar 7, 2021 12:44 UTC (Sun) by pizza (subscriber, #46) [Link] (5 responses)

> Quite the contrary. People had actual proper soundcards (me: ad1816 or cs46xx on daughterboards),

Just because you had high-end audio gear (for the time) doesn't mean most folks did. Even before Intel standardized onboard audio with the bog-simple single-stream AC97 spec, the overwhelming majority of the audio chips on the market only supported a single hardware PCM stream. Multi-stream hardware was always the upper echelon of the market.

> there was ALSA's dmix that would do software mixing via shared memory

I recall having a lot of issues with dmix in its early days. Not surprising as the same sorts of driver/library/application bugs that made PA a bit rocky also affected dmix.

PipeWire: The Linux audio/video bus

Posted Mar 7, 2021 15:15 UTC (Sun) by jengelh (guest, #33263) [Link] (1 responses)

>Just because you had high-end audio gear

I never thought of the two being particular high-end; ad1816 came with the package, the cs46xx was a 20€ second-hand thing.

PipeWire: The Linux audio/video bus

Posted Mar 10, 2021 3:28 UTC (Wed) by pizza (subscriber, #46) [Link]

The cs46xx series were multi-channel, multi-stream DSP-based 3d-positional-audio-capable controllers that were roughly comparable in capabilities to the Sound Blaster Live series.

(I owned a high-end CS4630 device in the late 2000 timeframe, mainly because it had drivers that were stable on the multiprocessor Win2K system that I was using for realtime video capture. I ended up selling it after that project was over due to zero Linux support..)

I stand corrected on the AD1816; a quick bit of research shows that supports six simultaneous streams mixed onto two output channels, although given its ISA nature it seems unlikely to achieve that with "CD quality" audio, and seems to have been sold nearly exclusively on bare-minimum cards as a super cheap way to met Microsoft's "MPC97" spec.

But yeah, these were both considerably more capable (at a chipset level) than most of their contemporaries. Until you pointed out the AD1816 I wasn't aware that any mainstream multi-stream ISA cards existed, and the PCI cards of that era tended to be the cheap bare-minimum crap that pretty much ended once onboard AC97 audio came along, leaving just the higher-end stuff targeted at gamers wanting to take advantage of native multi-stream 3D positional audio.

The market for all of this fancy stuff evaporated pretty quickly after Microsoft removed support for hardware-based multi-stream (and 3D positional) audio with Vista -- Despite the spec allowing for it, I don't know offhand of any "HD Audio" controller that implements multi-stream mixing; instead it's one stream per external audio codec. There may be more than one codec (ie two 2-channel codecs instead of one 4-channel codec) but that's pretty rare.

(Of course, pro audio hardware still exists, but those are nearly always single-stream-per-channel and rely on the CPU for mixing/dsp work, but specialized hardware can do whatever it wants, of course..)

PipeWire: The Linux audio/video bus

Posted Mar 8, 2021 14:21 UTC (Mon) by LtWorf (subscriber, #124958) [Link] (2 responses)

ALSA dmix is still there, it works fine. I've used it for years since I don't use pulseaudio because it's unpredictable and I don't feel like doing debug every time it fails.

Never had a problem with dmix.

PipeWire: The Linux audio/video bus

Posted Mar 9, 2021 16:39 UTC (Tue) by zlynx (guest, #2285) [Link] (1 responses)

People can say that about Pulseaudio too. Never had problems with it. Or not serious ones anyway. Yes, I have had it glitch and flip off USB headphones back to speakers or other things. But nothing seriously wrong.

Back when I ran Gentoo Linux I did run ALSA with dmix. And I did have problems sometimes. For example, if you nice some process which is acting as the dmix output to ALSA it gets under runs. If a process which is part of dmix gets hammered by OOM or a kill -9 signal things can get super messed up.

The best setup was on my home desktop running Gentoo because there I had a Soundblaster Audigy 2 card which managed a full 5.1 surround setup and I believe 16 independent input sources. The only real problem there was alsactl which had about 500 cryptically named visible controls.

PipeWire: The Linux audio/video bus

Posted Mar 9, 2021 17:32 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

Ah, I remember trying to find the right things to mute/unmute in ALSA's mixer even with a simple laptop setup. Many unfun times when you need to do it on a quick turn around time.

PipeWire: The Linux audio/video bus

Posted Mar 15, 2021 6:10 UTC (Mon) by flussence (guest, #85566) [Link]

For me it was that apps using sound would hang and require a `kill -9` if I dared use suspend-to-ram - the sound card driver itself was broken and required a rmmod/modprobe across suspends to fix. PulseAudio let me work around that, all I had to do was wrap the system suspend in pasuspender.

PipeWire: The Linux audio/video bus

Posted Mar 4, 2021 7:42 UTC (Thu) by josh (subscriber, #17465) [Link]

This was my experience as well. The ability to dynamically change where audio goes, to send it to a Bluetooth device or stream it over a network, without restarting applications? I was extremely impressed at the time.

PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 21:49 UTC (Wed) by ncm (guest, #165) [Link] (3 responses)

Everybody had trouble with PA, even people who liked it in principle.

LP wasn't joking about breaking sound: things did break, many, many times for many, many people, for years. And, almost always the only information readily available about what went wrong was just sound no longer coming out, or going in. And, almost always the reliable fix was to delete PA.

But it really was often a consequence of something broken outside of PA. That doesn't mean there was always nothing the PA developers could do, and often they did. The only way it all ended up working as well as it does today--pretty well--is that those things finally got done, and bulldozed through the distro release pipelines. The result was that we gradually stopped needing to delete PA.

Gstreamer crashed all the damn time, for a very long time, too. I never saw PA crash much.

The thing is, all that most of us wanted, almost all the time, was for exactly one program to operate on sound at any time, with exactly one input device and one output device. UI warbling and meeping was never a high-value process. Mixing was most of the time an unnecessary complication and source of latency. The only complicated thing most of us ever wanted was to change routing to and from a headset when it was plugged or unplugged. ALSA was often wholly good enough at that.

To this day, I have UI warbling and meeping turned off, not because it is still broken or might crash gstreamer, but because it is a net-negative feature. I am happiest that it is mostly easy to turn off. (I *wish* I could make my phone not scritch every damn time it sees a new wifi hub.)

Pipewire benefits from things fixed to make PA work, so I have expectations that the transition will be quicker. But Pipewire is (like PA and Systemd) coded in a language that makes correct code much harder to write than buggy, insecure code; and Pipewire relies on not always necessarily especially mature kernel facilities. Those are both risk factors. I would be happier if Pipewire were coded in modern C++ (Rust is--let's be honest, at least with ourselves!--not portable enough yet), for reliability and security. I would be happier if it used only mature kernel features in its core operations, and dodgy new stuff only where needed for correspondingly dodgy Bluetooth configurations that nobody, seriously, expects ever to work anyway.

What would go a long way to smoothing the transition would be a way to see, graphically, where it has stopped working. The graph in the article, annotated in real time with flow rates, sample rates, bit depths, buffer depths, and attenuation figures, would give us a hint about what is failing, with a finer resolution than "damn Pipewire". If we had such a thing for PA, it might have generated less animosity.

PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 22:35 UTC (Wed) by pebolle (guest, #35204) [Link] (2 responses)

> Everybody had trouble with PA, even people who liked it in principle.

Please speak for yourself.

PipeWire: The Linux audio/video bus

Posted Mar 4, 2021 3:55 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

ncm's statement is a bit of a hyperbole, but only a bit. Early PA had broken even the most basic setups that used bog-standard Intel sound chips.

It wasn't that hard to fix, but still.

PipeWire: The Linux audio/video bus

Posted Mar 4, 2021 9:51 UTC (Thu) by Wol (subscriber, #4433) [Link]

Setups that only worked because the user had tweaked OSS, ALSA etc to ****ery to force them to work ...

PulseAudio relied on the underlying layers working properly. For the most part, at the time, they didn't.

Cheers,
Wol