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

PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 13:14 UTC (Wed) by ms-tg (subscriber, #89231)
In reply to: PipeWire: The Linux audio/video bus by chris_se
Parent article: PipeWire: The Linux audio/video bus

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?

to post comments

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 (guest, #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 (subscriber, #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 (guest, #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 (subscriber, #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 (subscriber, #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.