Is there any experience with Ardour running on Wayland out there?
Any known issues?
I ran it for like a month or two. There are no problems as far as I could see, or that I could connect to Wayland. I had to go back to X for other reasons.
Plug-ins currently need X11 for their UIs. This will likely to be the case for some time (if not forever). There are currently some (incompatible with each other, non-âstandardâ - for some definition of âstandardâ, etc, etc) bespoke âsolutionsâ to making Wayland âcompatibleâ plug-ins (note the heavy use of quotation marksâŚ) but until some kind of consensus is reached, I suspect most host applications will need to run as X11 applications, for example using XWayland on Wayland native systems. Its basically the UI toolkit wars all over again as far as plug-in GUIs go, only this time it even extends to the underlying graphical subsystem.
1 Like
Iâve been using Wayland now for probably over a year, due to some apps that I found that didnât seem to work well in X11.
Iâve had a few little issues with it, but nothing major. Probably the biggest issue is that some legacy apps donât quite behave as they should when run with Xwayland.
For example, I used Krdc for some remote desktops with the freerdp plugin. FreeRDP should run within the Krdc window, but it tends to open itâs own window. Thereâs an environment variable you can set to stop it doing that. It took me a while to find, but itâs a simple fix.
Probably the only other issue I have had is if I hotplug a screen, it screws up the mouse coordinates, so the mouse pointer appears in the wrong place on the new screen.
Iâve used Ardour in it with no issues, including plugins.
I recently came across a bug which caused Ardour to crash, and my original assumption was it was a Wayland issue, but I rebooted into X11 and it did the same thing.
I will disagree with this somewhat as the underlying components of Xserver are, effectively, abandonware now, although (thankfully) some work is still going on to fix the worst of the security issues that come up, but I suspect that will, eventually, start to decline.
Yes, thereâs been some spirited debate amongst users on the merits of X11 vs Wayland, but these seem to have been confined to end-users. As I see it, thereâs no significant debate amongst the developers and maintainers of Xorg, who seem happy for there to be a future without X11.
Even NVidia, who were one of the last dissenting voices supporting X11, are now supporting WaylandâŚ
Plugins only âneedâ X11 because theyâve been written with toolkits which use X11. I donât see any reason why a plugin couldnât be written with a GUI using toolkits that natively run on Wayland.
On the other hand, I donât see any compelling reason to do so, as XWayland works and writing such a GUI would break compatibility with users who are still using X11.
The way I see it, XWayland mostly works pretty well, and the developers anticipate it being required as a compatibility layer for the foreseeable future, and will continue to support and develop it, and people will continue to use it whilst X11 based distros exist, and probably beyond that.
There may be a point in the future where the majority of tookits and applications are completely Wayland native, but I think thatâs a long time in the future. It seems to me that the immediate future is applications running in Xwayland, and for some of us, thatâs already here.
Cheers,
Keith
2 Likes
The problem has always been (and still is) that for Linux host applications, a plugin developer canât know in advance which UI toolkit a host will be using (e.g. Qt, GTK ( and which GTK?) ) and canât realistically target all of them, and they donât play together well in a single application - and why should they.
On Windows (and MacOS) one can logically assume that there will always be e.g. an HWND, or an NSView because its a fundamental part of the OS GUI. The equivalent on Linux, the âlowest common denominatorâ which you could know would be present on all recent distros was X11 (and an XWindow ID).
âNativeâ Wayland support breaks this (actually âWaylandâ as far as I understand it isnât even a window manager in any sense that is similar to other OS, its a compositor, so the concept of being able to âcreate a windowâ for the plug-in in the conventional sense (or even embed a plugin window in a host) is not even represented in the same way.
An application / plugin developer would have to do all the traditional window management functions instead, presumably, or use some add-on toolkit (but which one, and presumably only the one the host uses etc)
This is kind of a unique to audio (and you could argue unique to Linux) âedge caseâ - as a plugin developer, its frustrating because I need to target as many host applications as possible just to make it viable. And given that in many cases the GUI is 90% of the plug-in (yes, really) maintaining 3 or 4 different strands, just for one OS is impractical.
(My solution was actually to write my own DAW, with its plugin format, and embedded UIs, but thatâs just the kind of random sh*t I would do, I really donât recommend itâŚ! ) it took me six months to get to this -
(And when I say âDAWâ its more just tracking with some editing, automation etc and its unlikely to ever be anything other than a personal project but I digress)
</shameless self promotion>
I guess weâll just have to see what eventually evolves as common consensus around native Wayland support. In the meantime XWayland seems to do the job. And there are some other plug-in extensions (Presonus I think have something)
3 Likes
I use Wayland in Ubuntu Studio.
The only problem I get is when I use plugins (some of them) in Yabridge. But I donât know if itâs because of Wayland or because Wine doesnât support Mesa for my video adapter (Haswell Vulkan). I really donât know about these things.
The issue is that I need to use OpenGL to see some plugin monitors (e.g. spectrograms).
Some of them donât re-render when I use a control (say a slide). I have to move the plugin dialog to see the change.
You may have to switch to X11. I had to.