PipeWire 0.3 Released With Redesigned Scheduling Code To Offer JACK2-Like Performance

[DanL]

Synced to the coming desktop release of course

Didn't you learn your lesson when you claimed that Xserver release was synced to GNOME release and the X dev told you to STFU? https://www.phoronix.com/forums/foru...71#post1141771

Oh, wait. You never learn. Your trolling is synced to your keyboard.

[ermo]

Would I be correct in thinking that not only Flatpak, but also Remote Desktop solutions on Wayland might benefit from Pipewire?

Which means that both KDE, GNOME and possibly anything relying on Mir's Wayland functionality would be potential beneficiaries?

[Guest]

GNOME and FreeDesktop are closely tied. That is why.


(Does not give you a chance to call GNOME the standard desktop though)

I agree with you, Gnoem and gtk+/- libs are just an alternative that someone can use or cannot use.

[andyprough]

I assumed pipewire would have dependencies like pulseaudio and systemd, but I don't see them listed for Arch. It will be good having something that gives you consistent sound through flatpak apps.

[Britoid]

Would I be correct in thinking that not only Flatpak, but also Remote Desktop solutions on Wayland might benefit from Pipewire?

Which means that both KDE, GNOME and possibly anything relying on Mir's Wayland functionality would be potential beneficiaries?

They can use Pipewire to get a stream from the compositor, but I believe it's another API to control the display.

Imho there should be a method to get a fd of the framebuffer from the display server, which would allow clients to encode (or not encode!) as they see fit, but I'm not sure if Pipewire does this yet.

[mppix]

GNOME:
1) A desktop environment designed for tablets, despite being used 99.9% on PC monitors and (non-touchscreen) laptops.
2) Released nearly 10 years ago and only just now beginning to be (barely) usable, with (barely) acceptable performance.
3) Who cares who prepared a patch if it's working and correct code? Linus didn't package your kernel.

This is probably the worst comment that I read here so far. An opinion disguised as fact, which are misleading at best
1) Says who? Gnome has a fairly consistent DE design that works for desktops and is usable on touchscreens. Does it make sense? .. if you understand the DE design guidelines. Do you have to like or use it? Absolutely not.
2) Gnome 3 works smoothly on any modern PC. Does it have bugs and can it be improved? Sure ... it's software.

Gnome (and KDE) are important for the ecosystem. Like it or not and use what you want.

3) Do you really think any distro is going to write the DE integration of a new audio/video subsystem?

[mppix]

Would I be correct in thinking that not only Flatpak, but also Remote Desktop solutions on Wayland might benefit from Pipewire?
Which means that both KDE, GNOME and possibly anything relying on Mir's Wayland functionality would be potential beneficiaries?

Gnome+wayland already uses pipewire+xdg_desktop_portal in gnome-remote-desktop since a while now.

https://wiki.gnome.org/Projects/Mutter/RemoteDesktop

The solution relies on standard VNC so no audio, file transfer etc.
Hoping for improvements, like Spice (that works very well with VM's).
Also, it would be really good to get to a point where every user get its own remote session instead of the default share-the-full-screen to everyone.

[DanL]

Don't feed the troll.

I prefer to feed the troll to accelerate the banhammer, which is remarkably sluggish here at Phoronix.

[tildearrow]

Imho there should be a method to get a fd of the framebuffer from the display server, which would allow clients to encode (or not encode!) as they see fit, but I'm not sure if Pipewire does this yet.

There is, in theory, by using DRM/KMS (see kmsgrab). It is not part of PipeWire though...

...plus you need a workaround for AMD cards (which have a terrible encoder by the way).

[Britoid]

There is, in theory, by using DRM/KMS (see kmsgrab). It is not part of PipeWire though...

...plus you need a workaround for AMD cards (which have a terrible encoder by the way).

I remember reading that this could allow no-copy low-cpu usage on OBS, but right now it would require root as there's no other way of getting the fb object.