LWN: Comments on "PipeWire: The Linux audio/video bus"

PipeWire: The Linux audio/video bus

ghane — Thu, 18 Mar 2021 12:13:28 +0000

Thank you, Hi-Angel, darwi.

I can confirm that both pulseaudio and pipewire are running, as systemd user services.

Thanks

PipeWire: The Linux audio/video bus

mgedmin — Thu, 18 Mar 2021 09:20:00 +0000

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

darwi — Wed, 17 Mar 2021 17:08:24 +0000

> How can I check if I am using it?

In your Ubuntu 21.04 setup, PipeWire is only used for camera multiplexing and Wayland screen sharing. It is not used for routing audio. This is why you still have the PulseAudio package installed, and enabled, by default.

PipeWire: The Linux audio/video bus

immibis — Wed, 17 Mar 2021 10:18:42 +0000

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.

KLANG

flussence — Mon, 15 Mar 2021 06:41:01 +0000

I clicked that link bracing for the worst based on the domain name, but it turned out to be from 2012 and, as you say, pretty well written. What 8 years of toxic SEO greed and no competition (RIP Kerneltrap) does to a website…

PipeWire: The Linux audio/video bus

flussence — Mon, 15 Mar 2021 06:10:58 +0000

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

Hi-Angel — Sun, 14 Mar 2021 13:24:50 +0000

I imagine you will not have a pulseaudio process running, i.e. executing


 λ ps aux | grep pulseaudio
constan+     610  1.4  0.1 3120980 14064 ?       Ssl  мар10  80:22 /usr/bin/pulseaudio --daemonize=no --log-target=journal

will not give you a pulseaudio process, similar to the output I here. Also, usually pulseaudio is enabled as a "user" systemd service. I imagine, it might be different depending on a distro, but at least on Archlinux I can check on it as:


 λ systemctl status --user pulseaudio
● pulseaudio.service - Sound Service
     Loaded: loaded (/usr/lib/systemd/user/pulseaudio.service; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2021-03-10 21:45:01 MSK; 3 days ago
TriggeredBy: ● pulseaudio.socket
   Main PID: 610 (pulseaudio)
      Tasks: 7 (limit: 9392)
     Memory: 14.4M
        CPU: 1h 20min 22.968s
     CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/pulseaudio.service
             ├─610 /usr/bin/pulseaudio --daemonize=no --log-target=journal
             └─704 /usr/lib/pulse/gsettings-helper

мар 10 21:44:51 constantine-N61Ja systemd[602]: Starting Sound Service...
мар 10 21:45:01 constantine-N61Ja systemd[602]: Started Sound Service.
мар 10 21:45:02 constantine-N61Ja pulseaudio[610]: Found duplicated D-Bus path for adapter /org/bluez/hci0
мар 10 21:45:02 constantine-N61Ja pulseaudio[610]: Found duplicated D-Bus path for device /org/bluez/hci0/dev_78_A7_EB_7A_3D_E2
мар 10 21:45:02 constantine-N61Ja pulseaudio[610]: Found duplicated D-Bus path for device /org/bluez/hci0/dev_41_42_51_CD_29_12

Please don't ask for Chromecast anywhere

Cyberax — Sun, 14 Mar 2021 04:47:27 +0000

KILL ALL HUMANS! ROBOTS RULE!

Hey, it seems to be working!

Please don't ask for Chromecast anywhere

calumapplepie — Sun, 14 Mar 2021 03:59:23 +0000

*cries in sextuple-digit account number*

PipeWire: The Linux audio/video bus

mkbosmans — Sat, 13 Mar 2021 13:24:54 +0000

Ah, that brings back some memories!

Yes, I think some of those problems were fixed about 10 years ago, with this commit and some of its parents:
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/co...

But those were of course fixes related to general buffer underrun, network latency and clock drift problems. For a periodically interrupted network connection the only solution would be larger buffers, thus more latency for network playback.

PipeWire: The Linux audio/video bus

oldtomas — Thu, 11 Mar 2021 10:21:46 +0000

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

ghane — Wed, 10 Mar 2021 06:25:11 +0000

Hi,

I am running ubuntu/hirsute on my laptop (which will become 21.04), and I see

pipewire/hirsute,now 0.3.22-2 amd64 [installed,automatic]

How can I check if I am using it? I see pulseaudio packages installed as well, FWIW.

--
Sanjeev

PipeWire: The Linux audio/video bus

pizza — Wed, 10 Mar 2021 03:28:22 +0000

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

emorrp1 — Tue, 09 Mar 2021 18:29:15 +0000

Well it is part of the Utopia team, otherwise smcv would have had to go via NMUs, but that does seem to be a very loose collection of desktop software. Some teams do make deliberate effort to upload each others packages (IIRC started by debian-med advertising team graphs), others contribute but tend to let the primary uploader do their thing.

This graph shows pretty clearly that the fiefdom culture is now largely an historical artifact, but ultimately everything relies on volunteers, and therefore interest/buy-in from someone other than the initial uploader.

PipeWire: The Linux audio/video bus

mathstuf — Tue, 09 Mar 2021 17:32:28 +0000

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

zlynx — Tue, 09 Mar 2021 16:39:46 +0000

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

LtWorf — Mon, 08 Mar 2021 14:21:46 +0000

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

joib — Mon, 08 Mar 2021 06:43:18 +0000

> I suspect PipeWire for audio might become the recommendation in the Debian 12 cycle if more knowledgeable maintainers step in.

Thanks for the heads-up, and for your work in this. Hope things get sorted out for Debian 12 and the next Ubuntu LTS (22.04?).

And getting a bit off-topic, this seems to be another example where the Debian "culture" (or what should it be called?) of packages by default being single-maintainer fiefdoms is hurtful to the project and users. Hopefully this can eventually be fixed as well (though I'm not holding my breath).

PipeWire: The Linux audio/video bus

jengelh — Sun, 07 Mar 2021 15:15:59 +0000

>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

pizza — Sun, 07 Mar 2021 12:44:45 +0000

> 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

jengelh — Sun, 07 Mar 2021 09:23:48 +0000

>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

BirAdam — Sat, 06 Mar 2021 05:22:19 +0000

Indeed. Yes.

http://opensound.com/

PipeWire: The Linux audio/video bus

pabs — Sat, 06 Mar 2021 01:58:42 +0000

Is OSS4 still developed?

PipeWire: The Linux audio/video bus

BirAdam — Sat, 06 Mar 2021 01:52:20 +0000

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

plugwash — Sat, 06 Mar 2021 01:01:35 +0000

Technically it's not select that is the problem per-se, it's the types and macros used alongside it which use a fixed-size array with no bounds checking.

PipeWire: The Linux audio/video bus

ecree — Fri, 05 Mar 2021 14:22:14 +0000

> 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

lathiat — Fri, 05 Mar 2021 08:11:15 +0000

15 years ago was March 2006. The first PulseAudio release was July 2004. Ubuntu shipped it by default in 2008.

Safe to say it might be worth trying again ;)

PipeWire: The Linux audio/video bus

WolfWings — Fri, 05 Mar 2021 07:00:43 +0000

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

zdzichu — Fri, 05 Mar 2021 05:56:55 +0000

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

hailfinger — Fri, 05 Mar 2021 00:06:52 +0000

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

zuki — Thu, 04 Mar 2021 21:39:42 +0000

Yep. Systemd does that since v240:

> The Linux kernel's current default RLIMIT_NOFILE resource limit for userspace processes is set to 1024 (soft) and 4096 (hard). Previously, systemd passed this on unmodified to all processes it forked off. With this systemd release the hard limit systemd passes on is increased to 512K, overriding the kernel's defaults and substantially increasing the number of simultaneous file descriptors unprivileged userspace processes can allocate. Note that the soft limit remains at 1024 for compatibility reasons: the traditional UNIX select() call cannot deal with file descriptors >= 1024 and increasing the soft limit globally might thus result in programs unexpectedly allocating a high file descriptor and thus failing abnormally when attempting to use it with select() (of course, programs shouldn't use select() anymore, and prefer poll()/epoll, but the call unfortunately remains undeservedly popular at this time). This change reflects the fact that file descriptor handling in the Linux kernel has been optimized in more recent kernels and allocating large numbers of them should be much cheaper both in memory and in performance than it used to be. Programs that want to take benefit of the increased limit have to "opt-in" into high file descriptors explicitly by raising their soft limit. Of course, when they do that they must acknowledge that they cannot use select() anymore (and neither can any shared library they use — or any shared library used by any shared library they use and so on). Which default hard limit is most appropriate is of course hard to decide. However, given reports that ~300K file descriptors are used in real-life applications we believe 512K is sufficiently high as new default for now. Note that there are also reports that using very high hard limits (e.g. 1G) is problematic: some software allocates large arrays with one element for each potential file descriptor (Java, …) — a high hard limit thus triggers excessively large memory allocations in these applications. Hopefully, the new default of 512K is a good middle ground: higher than what real-life applications currently need, and low enough for avoid triggering excessively large allocations in problematic software. (And yes, somebody should fix Java.)

PipeWire: The Linux audio/video bus

marcH — Thu, 04 Mar 2021 21:26:59 +0000

> 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

darwi — Thu, 04 Mar 2021 17:29:34 +0000

> However, *I* don't understand the pipewire code well enough to be the one justifying to the release team why we need any particular change

The PipeWire commit logs are also very terse, and a lot of times just one-liners with no further context. IMHO, the project should really improve its commit logs from now on, especially that distributions are beginning to adopt it by default.

In fairness, the source code was a real beauty to look at; but the commit logs… not so much.

PipeWire: The Linux audio/video bus

busman — Thu, 04 Mar 2021 17:01:27 +0000

Inspired by this article I migrated from Pulseaudio to Pipewire yesterday. In the beginning I had weird bluetooth issues

- bluetooth daemon crashed 3 times
- external headphones and speakers were available in Gnome Settings but no sound and when I tried to test them there were no left or right speaker to push in the dialog

Telling Gnome bluetooth settings to forget those devices and then pairing them again fixed all issues. All is well now :)

PipeWire: The Linux audio/video bus

vstarwalt — Thu, 04 Mar 2021 16:12:50 +0000

Thanks for the article especially all of the links to original sources.

PipeWire: The Linux audio/video bus

floppus — Thu, 04 Mar 2021 16:06:50 +0000

The trouble is, that breaks everything that uses select(2).

Difficult to see how you could avoid that without requiring applications to opt-in to a higher limit... which is what distros seem to be doing lately, by increasing the hard limit to 262144 or 1048576, while leaving the soft limit at 1024.

PipeWire: The Linux audio/video bus

sorpigal — Thu, 04 Mar 2021 15:45:09 +0000

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

mgedmin — Thu, 04 Mar 2021 14:42:28 +0000

Ooh, it works nowadays? I tried PA's network audio support exactly once, 15 years ago, and was disappointed to get short pauses exactly 2 minutes apart.

(Much much later I realized that this was probably NetworkManager asking my WiFi card to scan for available networks periodically, which interrupted the PulseAudio stream sufficiently long to cause sound dropouts.)

KLANG

lkundrak — Thu, 04 Mar 2021 13:55:38 +0000

This article was such a pleasure to read. Informative and very well written.
Thank you!

PipeWire: The Linux audio/video bus

smcv — Thu, 04 Mar 2021 13:44:16 +0000

If you think you can justify each line of diff to the release team, go for it (I'd suggest talking to Sjoerd, who uploaded 0.3.22 to experimental). Or, if there are individual commits that have a low regression risk and high importance, please go ahead.

However, *I* don't understand the pipewire code well enough to be the one justifying to the release team why we need any particular change, and it still seems to be at the stage of maturity where targeted bug fixes, higher-regression-risk feature work, and harder-to-review refactoring/restructuring are mixed into one stream of commits; so I don't feel comfortable treating it like I would treat a bugfix-only stable-branch, like (say) GNOME Shell 3.38.x.

Sorry, I've done what I can, and if other people can do a better job then I'll be happy to step out of the way, but I am not the person to make this happen myself.