In this post I’ll try to explain PipeWire in the most simple way possible, to make it accessible to others that want to start following this cool new project but that don’t know where to start. It’s especially important to do this to open the door for more people to join in and follow the current development, which is happening at a fast pace.
PipeWire is making its way into the generic Linux desktop market, so now is as good a time as ever to gain a better understanding of what it is and how it works.
For graphics and sound and other interface issues I worked at the API level mostly with OpenGL and DirectX (and other means to the same end) on Windows but the framework was there for an easy Linux port.
I read through most of that and don’t have the slightest clue what they are talking about. The dreaded Wayland gets a mention as an inspiration. Coincidence? The problem with some technical writing and I find this to be the biggest issue with Linux is the completely lack of readability. Absolutely no accomodation is made for anyone not deeply immersed in it. They don’t even make the effort to generalise or give equivalent examples. You’re just supposed to magically know it.
As an application level developer would I be expected to know this? A yes or no would do.
Generally, no. This is infrastructure to provide the mixing and routing that underlays the ALSA or PulseAudio or JACK API you or your higher-level API abstraction can continue to use for audio as desired.
As for video, if you’re already using GStreamer or something higher level that may delegate to it, like Qt Multimedia, then that should also be handled for you. (If not, then you may need to know the PipeWire APIs that supplant just directly opening
/dev/video0for exclusive access.)It’s similar to how you don’t need to know Wayland if you let SDL2 handle asking for an OpenGL surface to be initialized. All this stuff that’s being changed doesn’t affect “send chunks of PCM audio data to the playback device” or “Call OpenGL APIs”… just the process of initializing an audio/video source/sink or, for Wayland, a drawable surface, which is typically wrapped in a higher-level API abstraction anyway.
Back when I was a developer I coded my own framework. I didn’t rely on SDL or anything like that. My framework was built as a general application framework much like Borland’s VCL and did things which were impossible with SDL because it was a different architectural design. For Linux stuff I would gut SDL for ideas and refactor into my own framework. My code went as low level as it had to go for performance reasons. I had OpenGL, D3D, and GDI abstractions. On top of this I had a GUI abstraction and a stripped down game abstraction. Oh, the joys of window initialisation. It’s been a long time. Sigh.
I don’t know enough about Linux stuff to know how deep I would have to go. By the sound of it “it depends”. So mostly a no unless I want to avoid copyright infringement and supply my own framework code in which case it may be dig a little deeper. It’s been a long time since I looked but I guess parts of SDL could be wrapped and parcelled off to avoid GPL issues.
SDL is under the BSD-like zlib license. https://www.zlib.net/zlib_license.html
Thanks for the correction. It’s been years since I last looked at it.
Also, these days, Valve strongly encourages use of SDL so they can push compatibility and feature updates for unmaintained games, so it’d be better to try to get patches added to SDL2 than to replace it.
(Sorry for forgetting about this tab for over a week.)
Yeah, I’d need it explained like I’m a five year old. I saw a mapping of all the various sound apis years ago and it was just a tangled mess. Having said that for my uses sound on linux works well enough. The very few apps I’ve written that used sound used very high level apis and just worked as expected.
I know the one you’re talking about, and Linux sound is infamous. Nothing else I know is that big of a mess.
Basically, PipeWire is a message broker which will move audio and video streams between endpoints.
This is very well written article, and it’s purpose is to get people immersed in the inner workings of PipeWire.
It wasn’t catering to newbies which was nice considering deep, thoughtful articles designed to impart real knowledge are rare. There is a lot of shallow, surface level fluff out there, but this is not one of them.
At some point, an audience needs to be picked and a base level of knowledge has to be assumed to avoid writing a novel. I’ve written lots of tutorials, some aimed at non-technical people, and I’ve had to assume people know how to use a mouse.
Anyway.. Yes, there is a skills gap. The number of people who have the technical ability build these things, and the number of people who can clearly communicate the ideas to others is very small.
This slide show might help: https://embedded-recipes.org/2019/talks/pipewire-a-new-foundation-for-embedded-multimedia/
It’s not that kind of article.
No. You’re working on a different level. It’s the same reason application developers don’t need to know how a network works.