Live data from Hacker News

PipeWire: The Linux audio/video bus

lwn.net

121–130 of 203 posts

Re: PipeWire: The Linux audio/video bus

#121
post #120

Earlier quoted context omitted.

It's more than 20 years later and still I don't understand these complaints. ALSA was designed to have a broader API than OSS, and it has supported OSS emulation for quite some time. What else could have been done when OSS went non-free?

Same what FreeBSD has done: keep developing Open Source OSS. One implementation going non-free doesn't affect other implementations of the same API.

Didn't they do that by developing ALSA OSS emulation? That is effectively another implementation of the same API.

Re: PipeWire: The Linux audio/video bus

#122
post #49
post #36

Earlier quoted context omitted.

>This is compared to JACK, which I never managed to properly combine with PulseAudio. Yeah making PulseAudio play nice with JACK seems to be tricky. Over time I configured it in four different environments (different Linux Distributions and/or Versions) and for each of them I had to do things (at least slightly) differently to get them to work.

Using JACK apps to route between PulseAudio apps under PipeWire is magic, as is being able to turn on external DACs after login and still be able to use them with JACK apps without restarting any software. Also PulseAudio not randomly switching to the wrong sample rate when I open pavucontrol is a blessing. (And it's so easy to setup, at least on Arch Linux.). I have come to describe PW as like a superset of JACK and…

I've first read about PipeWire about two months ago and I'd really love to try it. But! My setup is working and I'm really not the kind of person who likes to unnecessarily tamper with a smoothly running system. So I'll probably try it the next time I need to do a fresh install. Promise!

Re: PipeWire: The Linux audio/video bus

#123
This looks promising for Linux audio. I spent some time investigating the state of Linux audio servers a while back while diagnosing Bluetooth headset quality issues and ultimately opened this bug: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/18...

Sounds like a lot of lessons have been learned from JACK, PulseAudio etc that have been factored in to the architecture of PipeWire. Maybe it really is the true coming of reliable Linux audio :)

Re: PipeWire: The Linux audio/video bus

#124
This is an exciting development. As someone who has supported the desktop use of Linux audio by community radio users I've found it very frustrating at times how things don't work. I remember a decade ago going to a presentation on Linux audio at Ohio Linux fest and the recently I decided to dive in and see what the best solution to coming up with a user friendly and fool proof audio setup (easier said than done). I found that JACK is still too complicated to setup for novices and pulse audio can just be inconsistent. So pipewire seems like it has a lot of potential and I'm excited that people are working on this. It'll perhaps make Linux audio better able to compete with coreAudio and whatever audio subsystem Windows uses. I especially appreciate that the flexibility and modularity allows both professional and consumer applications. The future is bright.

Re: PipeWire: The Linux audio/video bus

#126

Earlier quoted context omitted.

It does, exactly the same way as JACK, and you can even do it with pulseaudio apps! I could pipe audio from a firefox tab through guitarix (guitar amp emulator) into a second firefox tab if I wanted to. With just JACK or just Pulse this wouldn't be possible. And if I understand it correctly, it should work for video streams too. I'm imagining piping a screenshare through OBS before going into discord or something, sh…

You can do that in Pulse, by using null sinks and monitor sources.

I see what you mean, still a lot more complicated than just dragging a "wire" in qjackctl though.

Re: PipeWire: The Linux audio/video bus

#127
post #18

It's great to see pipewire coming along, pulseaudio development seems to (to a spectator) to have been a little.. well.. https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge... https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge...

While that seems like a huge cluster, it does kind of seem that the patch rejections come from a set of principles. If the patches would improve Bluetooth audio at the expense of breaking existing features, saying "we don't break existing features" is a valid position to hold.

Re: PipeWire: The Linux audio/video bus

#128

I have never had problems with audio on Linux. What problems does this solve?

Better sandboxing, basically.

A system was needed for video, turns out it was a good fit for audio.

Audio and video aren't that different, TBH (audio just has more alpha/blending rules, and lower tolerance on missed frames; video has higher bandwidth requirements). Wouldn't surprise me if both pipelines eventually completely converge. Both "need" compositors anyways.

Re: PipeWire: The Linux audio/video bus

#129

I'm just thinking of all the disparate use cases for Linux audio, all the disparate types of inputs/outputs, complex device types involved, etc. But then I think about pro-audio: * gotta go fast * devices don't suddenly appear and disappear after boot * hey Paul Davis-- isn't the current consensus that people just wanna run a single pro-audio software environment and run anything else they need as plugins within that…

But there's pro audio in a studio, and then there's people like me who occassionally record stuff on our normal desktop systems and find it annoying to remember / lookup how to switch audio stacks.

Re: PipeWire: The Linux audio/video bus

#130
post #71
post #50

Earlier quoted context omitted.

My understanding back in the mid 2000s when I first got into Linux was that OSS only let you play one audio stream at once, and the whole point of ALSA was that it let multiple applications access the sound card. I guess I could be remembering that wrong, but I know I was listening to multiple audio streams long before PulseAudio came onto the scene.

OSS in non-free versions supported multiple sources. Linux sound guys decided that instead of fixing the free OSS they would write ALSA. They never really worked out all the bugs around mixing before pulseaudio took over.

PulseAudio and PipeWire embody the correct approach. The problem with OSS is, if you're using anything resembling modern audio formats, it risks introducing floating-point code into the kernel, which is a hard "no" in mainline Linux. So if you need software mixing, it should be done in a user-space daemon that has exclusive access to the sound card.
Post reply on HN