Pipewire should be the next generation video and audio streaming server. To cite the project website: > PipeWire is a project that aims to greatly improve handling of > audio and video under Linux. It aims to support the usecases > currently handled by both PulseAudio and Jack and at the same > time provide same level of powerful handling of Video input > and output. Would be nice, if there is a package for it.
https://github.com/PipeWire/pipewire it is already available in many distributions: https://repology.org/metapackage/pipewire/versions Please test and improve the ebuild in the Gentoo overlays http://gpo.zugaina.org/media-video/pipewire
Created attachment 575372 [details] pipewire-9999.ebuild Here's a start... still pretty crude with lots of untested bits. Took me a while to figure out that pipewire master is quite broken and the "work" branch is where main development is happening. Probably have to start the server from the /usr/$LIBDIR/pipewire-0.3 CWD to get the examples to run from the config file.
Created attachment 575616 [details] pipewire-9999.ebuild Manually install the spa/utils/result.h header, which is required by =kde-plasma/xdg-desktop-portal-kde-5.15.4 (which appears to have an automagic pipewire dependency; presumably that only can be sensibly fixed once pipewire is in-tree or in an overlay).
Created attachment 576238 [details, diff] xdg-desktop-portal-kde-pipewire_work_compat-20190512.patch The only ebuild I've stumbled across that straight up fails to build due to the above pipewire-9999 variant simply being installed is kde-plasma/xdg-desktop-portal-kde. There is dependency-grabbing auto-magic, there (technically a Gentoo ebuild bug, but treating it as such seems like overkill*). -- * because, strictly speaking, this probably belongs in a separate kde-plasma/xdg-desktop-portal-kde bug, or even a kde bug-report. But is it even a bug? They (KDE upstream) are just basing their code on "master" which is very likely a reasonable choice for them right now. Anyhow, the above words are just my excuse for wedging this here instead of somewhere more appropriate. Sticking it in /etc/portage/patches/kde-plasma/xdg-desktop-portal-kde-5.15.5 seems like a reasonable starting point for someone with the above =media-video/pipewire-9999 installed and a @world set depending on kde-plasma/xdg-desktop-portal-kde::gentoo. I'm getting no mileage out of it in practice but ymmv
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=862fe9600d20ddb26d990f1b509ff337637e70a2 commit 862fe9600d20ddb26d990f1b509ff337637e70a2 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2019-07-07 15:09:07 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2019-07-07 15:51:01 +0000 media-video/pipewire: New package, 0.2.6 initial version Bug: https://bugs.gentoo.org/667014 Package-Manager: Portage-2.3.68, Repoman-2.3.16 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> media-video/pipewire/Manifest | 1 + .../files/pipewire-0.2.6-alsa-lib-1.1.9.patch | 66 ++++++++++ ...pewire-0.2.6-fix-probing-without-starting.patch | 63 ++++++++++ .../pipewire-0.2.6-reuse-fd-in-pipewiresrc.patch | 137 +++++++++++++++++++++ .../pipewire-0.2.6-revert-combine-all-perms.patch | 34 +++++ media-video/pipewire/metadata.xml | 15 +++ media-video/pipewire/pipewire-0.2.6.ebuild | 88 +++++++++++++ 7 files changed, 404 insertions(+)
So this is masked for now to give some time for potential revdeps having any automagic fixed, one of them might be x11-wm/mutter based on grep. Arch is also listing chromium in revdeps.
I unmasked it after adding subslot. asturm will look over the consumers, add subslot operator dep where necessary and take care of the package.use.mask entries. Closing bug now as pipewire itself is in ~arch now.
I think the folks behind pipewire are a bit prone to slightly hyperbolic statements. It's nowhere near ready to replace pulse, jack, the Appalachian Mountain Hog Fiddle, or anything else you might use to put sounds on your computer or in your ear holes on a daily-basis. There is no official future of linux audio -- that will be whatever the open source community builds and uses. I really wish projects wouldn't say things like that. Second, I really do wish pipewire was a fully-realized implementation! But right now, it isn't. That's OK, they've just got some work to do. We know how premature audio server adoption plays out by now: by the time they sort the issues out, developers and users alike wind up wanting nothing to do with it. I really hope Big Blue Hat can figure out that maybe what's called for is to hire some unlucky guys to sit in a lab with a bunch of cards and laptops and do some old-school hardware-software matrix QA -- the usual FOSS approach of making users into guinea pigs is just too traumatic for everybody when your project is an audio server :) Anyhow my point is, I appreciate your enthusiasm, gerion, but imo, Gentoo does not need to rush out and do anything /tut suite/, just because pw is "the future of desktop audio." Look at the commit logs in the pipewire git repo and you'll probably see what I mean -- it's gonna be a while. When it's ready, Gentoo's job should be pretty easy; otherwise, it's a big mess to sort out & SHTDI.
(In reply to Greg Turner from comment #8) > SHTDI That stated, nice to see we've got a package in the tree now :)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=73e23d84f585147c36b9fe8f33dbecf0650ffcc5 commit 73e23d84f585147c36b9fe8f33dbecf0650ffcc5 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2019-08-17 22:01:25 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2019-08-17 23:02:00 +0000 profiles: amd64: Move media-video/pipewire USEes to p.use.stable.mask Bug: https://bugs.gentoo.org/667014 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> profiles/arch/amd64/package.use.stable.mask | 7 +++++++ profiles/base/package.use.mask | 7 ------- 2 files changed, 7 insertions(+), 7 deletions(-)
The in-tree pipewire 0.2.6 version doesn't do anything with audio yet, as far as I know. That comes in a future version (worked in git non-master branches upstream, so activity is harder to detect). We need it for its video capabilities to support remote desktop/screen sharing under wayland desktops (gnome-shell running in wayland and plasma running in wayland; gnome-shell made the code uniform too for less maintenance, thus needs pipewire for X11 screen sharing too, unsure about plasma on that). That said, once it does, I hope Gentoo isn't the last to (optionally) provide support for using it. We should be the bleeding edge here, not last one to jump to it - especially as we can usually give the choice in USE flags.
(In reply to Mart Raudsepp from comment #11) > <snip> We should be the bleeding edge here Hmm, yeah I guess I always focus on more of the pulseaudio-ish stuff since that's what I came to the party wanting to fix. But having watched some videos and stuff, I did get the impression that, in fact, the pulseaudio-ish-pw-stuff is kind of less core than the gsteamer-ish-pw-stuff (obv. a full gstreamer-grade pw would have audio capabilities though, so maybe not). As for bleeding edge, there's little point maintaining ebuilds that don't make somebody's day better. There's a figurative (metaphorical) bleeding edge where you flew too close to the sun and got a paper cut due to embarrassing metaphor mixup but it was a great ride. Then there's the the literal (colloquial) kind of bleeding edge, i.e., the kind where you'd better have fire-extinguisher, a fume hood, and separate refrigerators for lunch and work :) pw seemed to offer a bit of both. For ~amd64, pw stable just didn't work right. I'm not sure it came down to missing functionality so much as too many bleeding-edge revdeps causing it to just crash (guessing mostly). Whereas their "b.e. pain in the lambda" branch (not what it's really called of course) was actually pretty stable for me (just still not quite up to daily-drive-able status -- I did a few hours of torture testing (mostly alsa plugin <-> pw slice-and-dice <-> alsa plugin stuff with a coupleof native clients tested) and over a few hours of torture I took a couple of unplanned trips to the framebuffer console. That's really pretty impressive for a freshly baked codebase, I was practically fuzzing the thing. But it'd feel a lot less impressive if, say, I did apt-get upgrade on my work PC, and, oh, wierd, why did apt autoremove just get rid of pulseaudio? Let's ask Google... crap! just crashed to framebuffer console due to "illegal browser invocation" :)
@Greg Turner: Appearently there is little progress for now, however, what makes me hope that this is more like a "we need a new standard that is replacing the ones before" is that pulseaudio and jack developers are both involved here (see for example https://wiki.gnome.org/Hackfests/PipeWire2018). Also the need to play stuff within namespaces is not covered anywhere else if I'm right. Summarized: Maybe the project can reach its aims, maybe not, but it is a normal software project, which can be tested. Packages helps a lot here, so thank you for packaging.
