I couldn’t find an answer to this on the site, so I thought I’d ask here. I use Ubuntu 22.04 which is a pretty common distro. Ardour is already in the repos, but an old version. Do you offer deb packages for Ardour 8 so that it can fit nicely with my other software? Thanks
It’s not a deb package, it’s a self extracting installer, it works with Debian based distros.
Official Ardour Linux binaries are not distribution dependent, and hence not use a distribution package format (deb, rpm, slp, tgz, etc).
Ardour binaries do install to /opt to not interfere with any distro packaging (and come with an uninstaller, too).
Ardour uses makeself.io (same as steam, nvidia drivers etc). A self-extracting installer.
What about immutable distros that don’t allow copying to opt?
You could specify another path check Ardour-*.run --help, or just temporarily grant permissions to write there (like package installers do).
Immutable distros are mainly for server and environments where security matters. This is of little concern for pro-audio where everyone is comfortable to load arbitrary 3rd party plugins into a shared memory space, and execute them with realtime priority…
Besides, you do not want any containerization or sandboxing for DAWs and plugins because that significantly reduces performance.
–
PS.
You can also set INSTALL_DEST_BASE env variable before running the Ardour installer (default, when unset is /opt)
1 Like
Nevertheless, it was a question I was curious about. Many home users are starting to use Silverblue or Vanilla. The opportunity presented itself, so I asked. Thank you for your answer and workaround solution.
You can extract the .run files as well and then you can put them wherever you like and run from the extracted bundle folder. I do this in AV Linux because I need to wrap Ardour’s own bundle in a deb for my build system (it assembles from debs) but it’s still a deb of the official Ardour bundle…
*Bundle-Name --noexec --target /path/to/where/extracted
Next AV Linux will have a Custom Action script for this… basically for me… 
2 Likes
The only reason for that I can think of would be seccomp filters, and that should have gotten better with Linux ~5.10 IIRC. Can you elaborate on that a little? As in, what is it that’s making the applications slower here?
Context Switches. There is a penalty incurred by hardware when processes change from one program to another. Even on modern systems they can take up significant time (on the order of audio processing callbacks).
Oh then maybe I was too focused on Flatpak/Bubblewrap. For those, I would expect the performance impact to be negligible. From what I understand, bubblewrap relies on user namespaces and seccomp filters for its sandboxing. The former are set up on process start, the latter are used to filter syscalls in kernelspace, which means they should be evaluated during an already in-progress context switch. I haven’t done any benchmarks, though.
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.