Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PipeWire: The Linux audio/video bus

lwn.net

Post reply on HN
Print view View original

111–120 of 203 posts

Re: PipeWire: The Linux audio/video bus

#111

Post by JeremyNT »

chenxiaolong wrote: post #10

I've been trying out the latest master builds of pipewire recently and have been pretty impressed with it: * My bluetooth headset can now use the HFP profile with the mSBC codec (16 kHz sample rate) instead of the terrible CVSD codec (8 kHz sample rate) with the basic HSP profile. * Higher quality A2DP stereo codecs, like LDAC, also work. * AVDTP 1.3 delay reporting works (!!) to delay the video for perfect A/V sync.…

If you use Arch Linux, it's really easy to just drop this right in from official packages as a replacement for Pulse/ALSA [0] and start using it. I've been running it for about a month and everything seems to work exactly as I expect it to. I honestly notice no difference other than the pulse audio input/output picker extension I had been using seems confused now (the native GNOME sound control panel applet works just fine though).

On the video front I use obs-xdg-portal for Wayland screen capture as well - finally there's a good story for doing this! You even get a nifty permission dialogue in GNOME. You have to launch OBS in forced wayland mode with 'QT_QPA_PLATFORM=wayland obs'

[0] https://wiki.archlinux.org/index.php/Pipewire#Audio

Re: PipeWire: The Linux audio/video bus

#112

Post by admax88q »

cycloptic wrote: post #100
vlovich123 wrote: post #92

Earlier quoted context omitted.

To this day I still don't understand why messages are routed through dbus-daemon instead of just using FD-passing to establish the p2p connection directly. I remember we were using D-Bus on WebOS @ Palm & a coworker rewrote the DBus internals (keeping the same API) to do just that & the performance win was significant (at least 10 years ago).

Among other things, pushing everything through the message bus allows for global message ordering, and security policies down to the individual message. Rewriting the internals would work in an embedded situation like that where every application is linking against the same version of libdbus, but that is not really the case on a desktop system, where there are multiple different D-Bus protocol implementations. If ap…

Also lets you restart either end of the connection transparently to the other end.

With fd passing, if the daemon I'm talking to dies or restarts my fd is now stale and i have to get another.

Also allows starting things on demand similar to inetd.

Also allows transparent multicast.

So yeah, fd passing would be faster, but routing through the daemon is easier.

Re: PipeWire: The Linux audio/video bus

#113

Post by fulafel »

chenxiaolong wrote: post #10

I've been trying out the latest master builds of pipewire recently and have been pretty impressed with it: * My bluetooth headset can now use the HFP profile with the mSBC codec (16 kHz sample rate) instead of the terrible CVSD codec (8 kHz sample rate) with the basic HSP profile. * Higher quality A2DP stereo codecs, like LDAC, also work. * AVDTP 1.3 delay reporting works (!!) to delay the video for perfect A/V sync.…

Why would this affect bluetooth codecs?

Re: PipeWire: The Linux audio/video bus

#114

Post by teddyfrozevelt »

severino wrote: post #97
pta2002 wrote: post #5

Just tried it on NixOS, had no idea it was so fleshed out already! Thought it'd be full of bugs but was pleasantly surprised, it just worked. No issues with compatibility, extremely low latency and has JACK and PulseAudio shims, so everything works out of the box, including pro audio stuff like Reaper and Ardour. And thanks to the JACK shim I can patch around the outputs with qjackctl. This is compared to JACK, which…

I gave JACK a try more than a decade ago, and I remember how cool it was to be able to pipe the audio from one application to the input of another (unrelated) app, possibly adding effects or transformations in between. But JACK never became "mainstream" so I never got to use it for anything serious, but I miss the flexibility it offered even for non professional use-cases. What I wonder is if PipeWire will allow this…

I'm running PipeWire on Arch and I can do it through `pw-jack carla`[1]. You can do surprisingly advanced stuff through the JACK compatibility.

[1] https://i.imgur.com/EFUxR41.png

Re: PipeWire: The Linux audio/video bus

#115

Post by kaba0 »

kevincox wrote: post #23
pta2002 wrote: post #5

Just tried it on NixOS, had no idea it was so fleshed out already! Thought it'd be full of bugs but was pleasantly surprised, it just worked. No issues with compatibility, extremely low latency and has JACK and PulseAudio shims, so everything works out of the box, including pro audio stuff like Reaper and Ardour. And thanks to the JACK shim I can patch around the outputs with qjackctl. This is compared to JACK, which…

Thanks for the datapoint. I've been following https://github.com/NixOS/nixpkgs/issues/102547 and considering trying it out for a while. Did you just set services.pipewire.pulse.enable=true? https://search.nixos.org/options?channel=unstable&show=servi... My major concern is that I use PulseEffects as a key component of my setup so I'll need to check if that works well with PipeWire. But the only way to be sure is to t…

I just tried it on NixOS and the new version is already packaged and working.

Re: PipeWire: The Linux audio/video bus

#116

Post by cycloptic »

admax88q wrote: post #112
cycloptic wrote: post #100

Earlier quoted context omitted.

Among other things, pushing everything through the message bus allows for global message ordering, and security policies down to the individual message. Rewriting the internals would work in an embedded situation like that where every application is linking against the same version of libdbus, but that is not really the case on a desktop system, where there are multiple different D-Bus protocol implementations. If ap…

Also lets you restart either end of the connection transparently to the other end. With fd passing, if the daemon I'm talking to dies or restarts my fd is now stale and i have to get another. Also allows starting things on demand similar to inetd. Also allows transparent multicast. So yeah, fd passing would be faster, but routing through the daemon is easier.

I didn't mention those because in theory a lot of that could be done by the library, or done by the daemon before passing off the fd for a peer-to-peer connection. (If a connection dies, the library would transparently handle that by sending a request back to the daemon for another connection, etc) But of course another thing that having a message bus allows you to do is reduce the amount of fds that a client has to poll on to just one for the bus socket.

Re: PipeWire: The Linux audio/video bus

#117

Post by capableweb »

pta2002 wrote: post #5

Just tried it on NixOS, had no idea it was so fleshed out already! Thought it'd be full of bugs but was pleasantly surprised, it just worked. No issues with compatibility, extremely low latency and has JACK and PulseAudio shims, so everything works out of the box, including pro audio stuff like Reaper and Ardour. And thanks to the JACK shim I can patch around the outputs with qjackctl. This is compared to JACK, which…

> extremely low latency

How low is "extremely low", especially compared to JACK that I'm currently using when doing music production?

Re: PipeWire: The Linux audio/video bus

#118

Post by Nullabillity »

pta2002 wrote: post #110
severino wrote: post #97

Earlier quoted context omitted.

I gave JACK a try more than a decade ago, and I remember how cool it was to be able to pipe the audio from one application to the input of another (unrelated) app, possibly adding effects or transformations in between. But JACK never became "mainstream" so I never got to use it for anything serious, but I miss the flexibility it offered even for non professional use-cases. What I wonder is if PipeWire will allow this…

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.

Re: PipeWire: The Linux audio/video bus

#119

Post by Delk »

onli wrote: post #37
jcastro wrote: post #32

Earlier quoted context omitted.

> I'm not sure why this seems to be remembered so wrongly? It didn't work reliably on all chipsets/soundcards.

I don't remember this at all, but this might explain that. Or maybe a distribution like debian stable shipped with an outdated ALSA version, taken from the short period between release and dmix. Or just disabled dmix. Would love if someone remembered specifics. I kinda assumed people mix up Alsa and OSS or don't remember anymore what actually did and what did not work before Pulseaudio was introduced.

In the early 00's (before PulseAudio), my desktop had an old SoundBlaster Live PCI card that was pretty common around the turn of the millennium. ALSA dmix Just Worked with that one.

Any other hardware I encountered required some kind of software mixing, IIRC. Not that my experience was extensive, but I got the impression that hardware or driver support for dmix wasn't that common.

Re: PipeWire: The Linux audio/video bus

#120

Post by trasz »

cycloptic wrote: post #109
bluGill wrote: post #71

Earlier quoted context omitted.

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.

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.
Post reply on HN