Pipewire for linux


#1

I think my previous posting of this wasn’t thread-appropriate, or just barely. Anyway! Pipewire is still interesting to me, I still haven’t tried it out yet except for mundane stuff on a work computer. (And still works great for that.)

Pasting what I wrote below but I’m pretty excited about something from redhat/fedora (I mean, they have made a lot of lovely and stable/ongoingly-supported stuff for linux in the past, like probably all the stuff about gnome you like :stuck_out_tongue: and also other new exciting stuff like flatpak) that intends to replace/improve-on both pulseaudio (which is a pile of good intentions that I as a rule uninstall immediately if I want to do music work on linux) and jack which is kind of crazy…


#2

Do you know if pipewire already does any realtime audio stuff like JACK? I believe the focus has mainly been on video, right?


#3

They shipped the audio portion of it in the latest fedora ahead of any of the video stuff, I think at the moment the only released parts of pipewire are the audio components! I know it’s intended to do lots of wonderful realtime stuff, and from the stuff I’ve read they intend to support low level interfaces for developers to use as well – “graph based processing with support for feedback loops and atomic graph updates” seems like they have ticked the boxes i’m aware need ticking for that sort of thing :slight_smile:

Um, but! Still I’ve only done basic day-to-day audio stuff with it personally so I can’t speak to any of that from experience yet. Okay well now I think I know what I’m going to try to fuck with tonight. :-p


#4

Arch linux already has an offical package for pipewire – installing suggested I can install ffmpeg, libva and jack2 as deps which is interesting and makes me think pipewire may work WITH jack2 which would be amazing.

Created symlink /etc/systemd/user/sockets.target.wants/pipewire.socket → /usr/lib/systemd/user/pipewire.socket.
Optional dependencies for pipewire
    ffmpeg [installed]
    jack2 [installed]
    libva [installed]

#5

Okay the pipewire github repo readme says:

PipeWire is a server and user space API to deal with multimedia
pipelines. This includes:

  - Making available sources of video (such as from a capture devices or
       application provided streams) and multiplexing this with
       clients.
  - Accessing sources of video for consumption.
  - Generating graphs for audio and video processing.

Nodes in the graph can be implemented as separate processes,
communicating with sockets and exchanging multimedia content using fd
passing.

And here is a ticket on the repo where two folks ask months apart about docs for the project: https://github.com/PipeWire/pipewire/issues/9

So yeah this seems early days haha. Was hoping for a bit more documentation up front honestly given that it’s a fedora project but I’m sure it’ll come…


#6

Ah also some tidbits in a design txtfile in the repo:

PipeWire
--------

PipeWire is a media server that can run graphs of multimedia nodes.
Nodes can run inside the server or in separate processes.

Some of the requirements are:

 - must be efficient for raw video using fd passing and audio with
   shared ringbuffers
 - must be able to provide/consume/process media from any process
 - policy to restrict access to devices and streams
 - extensible

Although an initial goal, the design is not limited to raw video
only and should be able to handle compressed video and other
media as well.

PipeWire uses the SPA plugin API for the nodes in the graph. SPA is
a plugin API designed for low-latency and efficient processing of
any multimedia format.

Some of the application we intend to build

 - v4l2 device provider. Provide controlled access to v4l2 devices
   and share 1 device between multiple processes.

 - gnome-shell video provider. Gnome-shell provides a node that
   gives the contents of the frame buffer for screen sharing or
   screen recording.

 - audio server. Mix and playback multiple audio streams. The design
   is more like CRAS (Chromium audio server) than pulseaudio and with
   the added benefit that processing can be arranged in a graph.

 - Pro audio graph processing like JACK.

 - Media playback backend


Protocol
--------

The native protocol and object model is similar to wayland but with custom
serialization/deserialization of messages. This is because the datastructures
in the messages are more complicated and not easily expressable in xml format.


Extensibility
-------------

The functionality of the server is implemented and extended with modules and
extensions. Modules are server side bits of logic that hook into various
places to provide extra features. This mostly means controlling the processing
graph in some way.

Extensions are the client side version of the modules. Most extensions provide
both a client side and server side init function. New interfaces or new object
implementation can easily be added with modules/extensions.

Some of the extensions that can be written

 - protocol extensions: a client/server side API (.h) together with protocol
   extensions and server/client side logic to implement a new object or
   interface.

 - a module to check security of method calls

 - a module to automatically create or link or relink nodes

 - a module to suspend idle nodes

#7

The contents of the file PROTOCOL: 0 bytes

The file NEWS: the string PipeWire 0.1

There are a few examples though: https://github.com/PipeWire/pipewire/tree/master/src/examples

Okay I’m still sifting thru the pipewire source but also this blog post has good background: https://blogs.gnome.org/uraeus/2017/09/19/launching-pipewire/


#8

Oops, um I feel like an idiot. So I got to the end of that article and it said “video only for now!” and I swear I read the opposite when it was announced on LWN, but clearly I’m just an idiot. All this time I’ve been using my little default install of fedora at work thinking “gee audio works fine!” but it’s probably pulseaudio haha. Pulseaudio always was totally fine for that sort of thing. Anyway! Derp. I guess the audio layer ISN’T out, they shipped video first.

I’m still excited about it. :-p


#9

The last time I looked Pipewire had ideas which were not yet implemented, including many audio features. I’m curious which problem it solves that JACK does not already solve.


#10

From reading the speculative docs, it sounds like they want to cover Jack use cases and Pulseaudio use cases the same. So I’d guess/hope pipewire means to cover both.


#11

More news on pipewire! Looks like they’re already making progress on the audio side of things. They’ve implemented the jack API on top of it, and are working on ALSA compatibility:

https://blogs.gnome.org/uraeus/2018/01/26/an-update-on-pipewire-the-multimedia-revolution-an-update/


#12

Well, finally something somewhat tangible on the sound side of things :slight_smile:
Also, like @lazarello said, I’d be interested in what they are trying to do that JACK doesn’t already do? What’s the reason it exists and can/should replace JACK?

AFAIK no one working on pipewire has been in touch with any of the JACK devs, make of that what you will, but at the very least that’s a missed opportunity.


#13

Oh that’s a bummer.

To play devil’s advocate, the situation with jack & jack2 existing side-by-side, and the process of starting a Jack server alongside whatever Jack-enabled applications are desired seems like a stumbling point for new users, so if pipewire is transparent to new users, but also supported Jack, that seems like a win-win.

Generally though, I think their major goal is a system that has tight integration between the video and audio layers? From the blog post:

Another important goal of PipeWire was to bring all Linux audio and video together, which means PipeWire needed to be as good or better replacement for Jack for the Pro-Audio usecase.