If the problem is in the operating system, it doesn’t make sense to blame the application developers. It’s the same as if the road were full of potholes, your car broke down, and you blamed the car manufacturer. Good luck on your journey.
1 Like
I do understand your point and I also believe that bleeding edge Distros are bad choices for ‘purpose-driven’ applications like Audio Workstations… However your analogy doesn’t exactly hold up because given that the road has potholes the Ardour ‘vehicle’ is breaking down and the Reaper one isn’t… in that case there may be agreement that the road needs fixing but you also may have a case to complain to the vehicle manufacturer, or look elsewhere for a better-suited vehicle.
I think a product like Ardour that has an established, patched and mature set of core support libraries is going to occasionally not mesh with bleeding edge Distros, in similar ways other bundled things like AppImages also don’t work forever… You can’t fault Ardour for building a reliable bundle and you can’t fault Arch Linux for being what it says on the can… I think there are a LOT of Users somewhere in the middle of all of that and I would guess that would be a sensible place for Ardour’s priorities to be.
2 Likes
Thanks for testing. The mystery remains though.
Reaper is a fine DAW, too. and hey, whatever works.
2 Likes
Maybe Ardour could use some hot rod suspension to better handle the bumps of distros like Arch. 
1 Like
And, specifically, it states:
It is the user who is ultimately responsible for the stability of their own rolling release system
Implicitly, that includes the stability of applications they wish to run in their choice of OS.
I see this as putting the onus on the end-user to make things work. If they can’t, then I would suggest the user shouldn’t be using Arch (and I suspect the Arch maintainers would agree).
complaints of breakage are misguided and unproductive
Cheers,
Keith
2 Likes
So I think I finally found the error.
It seems to be a mesa 25.2.2-4 issue on my hardware.
I’m on amdonly-gaming-mesa-git 25.3.0 now:
Everythings working again, no crashes, no plugin issues anymore.
Still wondering why this did only affect Ardour…?
1 Like
So it would be logical to admit that when you said "
Changing OS, because of one Software that is buggy most of the time?
Everything else working. That’s rediculous. Therefore Ardour is simply not good enough.
In the past year I’ve been using Reaper (and Qtractor) I had zero issues with plugins or Crashes. That means more time for making music. That’s what counts for me.
If you really recommend changing OS you should consider admitting that Ardour is not working on all modern Linux Platforms and give a clear recommendation for a specific Linux OS to only use with Ardour.",
in this case it was largely unfair to Ardour and its development, since you had tinkered with your distribution using AUR or Git packages for gaming .
If we did the same thing on Windows, I doubt that a series of software would work as well.
I’m not blindly defending Ardour, but in this case…
And I don’t blame the approach of tinkering with a distribution. I do it myself often. But in the case where it doesn’t work, I avoid getting angry with the developers.
Besides, I personally gave up on the idea of having a Linux distribution that works for both gaming and pro audio use. It’s either one or the other.
1 Like
This is exactly why, especially in media production — whether it’s audio or video — it’s recommended to use a distribution tailored for that purpose, such as Ubuntu Studio, AV Linux, or similar. These systems are designed so that things just work out of the box without extra tweaking. If you’re using a general-purpose distro that’s been customized for something like gaming, you really need to have a deep understanding of how Linux works to keep the system stable and reliable for production use.
The same principle actually applied in the Windows world as well, especially in the past: if a machine was used for professional production, nothing else was done on it. No games, no experiments, not even casual web browsing. Just work — to keep the environment predictable and consistent.
In media production, stability always takes priority — regardless of the operating system.
From my perspective, the Ardour developers are top experts in their field and have clearly done significant pioneering work. As a recording and mixing engineer, I don’t feel I have enough grounds to criticize their work negatively — nor do I have the need or desire to do so. However, I certainly have plenty of positive and kind things to say about them.
4 Likes
I am glad you found the issue, and thank you for sharing the solution.
If I had to guess: Ardour does not sandbox plugins and runs them all in the same process. In the past we’ve seen issue with nouveau when one than one window in a given process uses openGL. Maybe something similar sneaked in to mesa…?
That’s why I prefer ‘stable’ Linux distributions. Even if there some bug appears, I is a high probability that it already has been fixed in the new version of software and back-ported into the repository of stable distribution. It just works and does not force me to jump across the forums looking for a solution of the problem in the third-party software.
7 Likes
There are crashes with LSP 1.2.23 happening in Ardour 8.12 and Ardour 9.0pre0.
Insert LSP-VST3 Plugin in an audio Track, try to remove the plugin → Crash
Same with Ardour 9 happening in audio Tracks, or Region FX.
Downgraded to LSP 1.2.22 and the issues are gone!
https://forum.harrisonconsoles.com/thread-12659-post-72164.html#pid72164
1 Like
I had the same problems with VST3. VST2 and lv2 are working fine on Ardour 8.12 (Ubuntu mate 22.04)
Reproduced the problem on Ardour-8.6.365.
@x42
I see that IPlugView::setFrame is called with NULL frame argument.
This forces LSP Plugins to re-setup IEventHandler and ITimerHandler for the IRunLoop interface.
After that, the destructor for IPlugView is called without calling the IPlugView::removed method whith removes IEventHandler and ITimerHandler from IRunLoop.
After that, Ardour crashes here:
(gdb) bt
#0 0x00007ffff70a4547 in AVST3Runloop::timeout(void*) () from /opt/Ardour-8.6.365/lib/libardour.so.3
#1 0x00007ffff04574b9 in ?? () from /opt/Ardour-8.6.365/lib/libglib-2.0.so.0
#2 0x00007ffff045694a in g_main_context_dispatch () from /opt/Ardour-8.6.365/lib/libglib-2.0.so.0
#3 0x00007ffff0456ce8 in ?? () from /opt/Ardour-8.6.365/lib/libglib-2.0.so.0
#4 0x00007ffff0457002 in g_main_loop_run () from /opt/Ardour-8.6.365/lib/libglib-2.0.so.0
#5 0x00007ffff2d737d7 in gtk_main () from /opt/Ardour-8.6.365/lib/libytk.so.2
#6 0x00007ffff4664d65 in Gtkmm2ext::UI::run(Receiver&) () from /opt/Ardour-8.6.365/lib/libgtkmm2ext.so.0
#7 0x00005555558ac6fe in ?? ()
#8 0x00007ffff403e24d in __libc_start_main () from /lib64/libc.so.6
#9 0x00005555558b39ba in ?? ()
I see from my side that I need to more carefully remove IRunLoop handlers. But the behvaiour of Ardour is strange, too.
The runloop meanwhile moved to the backend and the null argument was also meanwhile fixed. That change happened in 8.6-459-gc77d2d42b9 (over a year ago).
The user however reported the issue to be present in recent Ardour 8.12.
–
PS. these may be pertinent:
The last change is only in Ardour 9 / git.
@x42 verified on the latest Ardour build.
The problem still persists:
(gdb) bt
#0 0x00007ffff79b08c7 in AVST3Runloop::timeout(void*) () from /opt/Ardour-9.0.pre0.1806/lib/libardour.so.3
#1 0x00007ffff5dd951a in ?? () from /opt/Ardour-9.0.pre0.1806/lib/libglib-2.0.so.0
#2 0x00007ffff5dd894f in g_main_context_dispatch () from /opt/Ardour-9.0.pre0.1806/lib/libglib-2.0.so.0
#3 0x00007ffff5dd8cf8 in ?? () from /opt/Ardour-9.0.pre0.1806/lib/libglib-2.0.so.0
#4 0x00007ffff5dd9023 in g_main_loop_run () from /opt/Ardour-9.0.pre0.1806/lib/libglib-2.0.so.0
#5 0x00007ffff620339a in gtk_main () from /opt/Ardour-9.0.pre0.1806/lib/libytk.so.2
#6 0x00007ffff6a4dfdb in Gtkmm2ext::UI::run(Receiver&) () from /opt/Ardour-9.0.pre0.1806/lib/libgtkmm2ext.so.0
#7 0x0000555555ba3016 in ?? ()
#8 0x00007ffff4fa224d in __libc_start_main () from /lib64/libc.so.6
#9 0x0000555555ba8e9a in ?? ()
From the log of LSP Plugins:
[TRC][lsp-plugins/modules/lsp-plugin-fw/include/lsp-plug.in/plug-fw/wrap/vst3/impl/ui_wrapper.h: 605] removed: this=0x55555ca54400
[TRC][lsp-plugins/modules/lsp-plugin-fw/include/lsp-plug.in/plug-fw/wrap/vst3/impl/ui_wrapper.h: 739] setFrame: this=0x55555ca54400, frame=(nil)
[TRC][lsp-plugins/modules/lsp-plugin-fw/include/lsp-plug.in/plug-fw/wrap/vst3/impl/ui_wrapper.h: 762] setFrame: RUN LOOP object=0x7ffff7f1e9c0
[TRC][lsp-plugins/modules/lsp-plugin-fw/include/lsp-plug.in/plug-fw/wrap/vst3/impl/ui_wrapper.h: 72] ~UIWrapper: this=0x55555ca54400
The patch for LSP plugins is here:
So Ardour calls into the plugin from AVST3Runloop::timeout after the plugin has been removed? Unless the plugin itself first un-registers itself from the runloop?
What are the invalid API calls by the DAW that you refer to?
The problem here is that LSP plugins perform de-registration on IPlugView::removed() call.
But after that we receive IPlugVIew::setFrame() call where we set up IEventHandler and ITimerHandler back.
After that, the destructor for IPlugView is called and Ardour crashes trying to call IEventHanler or ITimerHandler because they are already bound to non-existing objects.
indeed close_view calls
_view->removed ();
_view->setFrame (0);
_view->release ();
where _view is-a IPlugView*
I do recall that _view->setFrame (0); was needed for some plugins, but it’s been 6 years and I can’t remember which. I also cannot find documentation if this sequence is the correct. Since you mentioned “invalid API call” is there some spec that I missed?
That code in question been like this since 2019, and no other plugins had issues with that so far… (knock on wood), So I’d be reluctant to change it unless required.
PS. JUCE also does this sequence:
I’m not sure. I just have what was written in original Steinberg’s SDK poor documentation. But I doubt that sequence removed + setFrame with nullptr as argument is a correct sequence.
Anyway, now I check the pointer passed to the setFrame and do not set up handlers if it is NULL.
Steinberg does it reverse:
…but since JUCE does it the other way around, and given JUCE’s popularity, I suppose plugins now have to handle both 
1 Like