Fedora Workstation 34 Should Be Very Exciting With GNOME 40, PipeWire Default

[LightBit]

Will I be able to use LADSPA plugin on PipeWire?
Will it be possible to revert back to PulseAudio?

[maage]

I'm still very skeptical about PipeWire. I've been testing it on and off in the last weeks. There are still numerous bugs, PulseAudio/ALSA compatibility issues and hardware incompatibilities. It's promising, but it's just too early for a general rollout.

I have now (pre-beta) F34 installed with latest Fedora pipewire packages.

Without local modifications audio playback was stuttering(?), playing couple of seconds and then pause and jump and repeat.

After I set this as pipewire-pulse.service override:

[Service]
Environment=PIPEWIRE_LATENCY=1024/48000 PIPEWIRE_LINK_PASSIVE=1

playback has been working somewhat.

But I still see lines like:

[ 2062.504361] pipewire[2428]: (alsa_output.usb-Focusrite_Scarlett_2i4_USB-00.analog-surround-40-42) XRun! rate:2048/48000 count:6 time:2062491963 delay:10483 max:11405

So I guess I need to increase latencty still.

Another issue is with moving audio from Scarlett to bluetooth is not seamless or automatic. I need to do it via pavucontrol. When BT speaker is powered off, it is not visible at all in pavucontrol. When I power onf BT speaker, it is visible as Off (unplugged) in pavucontrol and I need to select Profile and then select is as playback device. This is also something i am not able to do with current Gnome Settings Sound tab. I do not know if this BT issues is about pipewire as such, but it was working with pulseaudio, I just needed to power on BT speaker to move audio from headphones.

I had some problem with pulseaudio as sometimes it did not survive from suspend / moving devices away from the machine and such.

I'm not audio enthusiast, so mostly I just listen YT videos via browser. So my use case or applications are not something hard to test or exotic. Probably HW setup is not one of the most common.

[LightBit]

Will it be possible to revert back to PulseAudio?

[Britoid]

From a user perspective I do not really get why people are so invested in which part of the system is responsible for drawing the window border? You never hear these discussions on Mac or Windows. What is relevant is that the different applications support the system used so they get borders, but other than that I do not get it?

Mac is client side, Windows is weird, but on both OSs applications don't talk to the display server directly (unless you're a game), you talk to the OS toolkit instead which gives you a handle to draw your window, handles decorations and connects to the display server on your behalf.

Hence, because everything talks to that toolkit to create windows, Microsoft and Apple can update their display server APIs very easily as they just need to update their toolkits, as long as the exposed API to applications from that toolkit stays the same.


on Linux though, we don't have a single toolkit so everything implements its own connection to the X or Wayland server.


I'd love GTK to be used as a low-level window toolkit (e.g. Qt calls to it), but apparently it's absolutely shit at being so.

[juxuanu]

Meanwhile most Windows 95 32bit applications applications work flawlessly under Windows 10 and have all the features, while we're here talking about the specifics which are of zero use for the end user. Period. The end user wants to run his old applications and have the same features but XWayland barely provides anything outside of basics.

We are impatiently waiting for your money to pay the devs that make that happen (2/3 of the Microsoft Windows development team work on backwards compatibility)

Or your comparison between a multi-million corporation and a bunch of people developing on their free time is just to fulfill your desire of sticking out in the internet?

[You-]

Meanwhile most Windows 95 32bit applications applications work flawlessly under Windows 10 and have all the features, while we're here talking about the specifics which are of zero use for the end user. Period. The end user wants to run his old applications and have the same features but XWayland barely provides anything outside of basics.

Most.

Not all. If you are the user of that one piece of software that doesnt work, the rest doesnt matter.

(I have some 32 bit software that wont work on 64 bit windows)

[oiaohm]

An X11 application can have a systray icon under a Wayland session? Um, could you show a screenshot please? E.g. Audacious running with a GTK2 backend?

https://gould.cx/ted/blog/Having_a_tidy_systray/

There are two major systray protocol with X11. The new secure one starts in 2010 and is called XDG StatusNotifier it dbus based with zero dependency on X11. So a X11 application using XDG StatusNotifier displays its systray icon perfectly on Wayland desktops that have a system tray.

https://specifications.freedesktop.org/systemtray-spec/systemtray-spec-0.3.html

There is the older systemtray specification yes not updated since 2009. This depends on xembed and also due to design can send message to wrong application. That right you click on icon select menu item and its possible to have that message go to the complete wrong application.

It is possible to run https://github.com/kolbusa/stalonetray under Xwayland to support applications using the horrible broken protocol of xdg System tray.

Should horrible broken like xdg system tray this work out box most likely no. Applications still using xdg system tray need their users complaining so they update. Is it impossible for users to use those xdg system tray icons the answer is again no it just requires the user to run something like stalonetray before starting application to support the broken.

Yes stalonetray exists because not all X11 windows managers/desktops support having a system tray either. So audacious running on GTK2 backend without running extra software on lots of X11 windows managers/desktops before wayland you are not going to see the systray icon without running a third party application. So the issue you raised here is broken under X11 bare metal and the fix for when it broken on bar metal X11 is the same one you need todo on Wayland solutions so it works. Yes running stalonetray or equal in Xwayland is the fix.

2020 or not, Microsoft, Apple, Google - all major software vendors strive to provide perfect compatibility for old software (Apple often requires full recompilation but this doesn't imply any code changes) while Linux has its own way.

This is myth. Microsoft Apple and Google do break thing on security grounds requiring code modifications to fix. This system tray problem with X11 applications is in fact a security problem.

Yes this problem would be in the same class as need to under windows enabled compadiblity mode so something works with the compatibility mode be run a compatible xdg system tray. Yes just like compatibility mode on windows on wayland applications using xdg system tray should fail to have a system tray icon until user does something or the developer of application updates application.

[dragon321]

libdecoration can be good but maybe not... I didn't see a lot of activity here.

There is work in progress to implement libdecoration support for SDL. Developers are willing to accept this work so when SDL will pickup this, we can probably expect more projects to go that way. libdecoration itself has some progress but not in main branch. There is also work on GTK plugin which makes libdecoration decorated windows looks pretty native on GNOME.

[andrea76]

Can we have an horizontal taskbar without installing an extension?

[Alexmitter]

I'd love GTK to be used as a low-level window toolkit (e.g. Qt calls to it), but apparently it's absolutely shit at being so.

Flutter for example uses GTK to draw on Linux.