Why Linux is Becoming Impossible for Audio Developers to Ignore

[audiojunkie]

..

[audiojunkie]

Quick update for this thread: all my most prominent plugins now have Linux builds available. So the "he doesn't support Linux" concern should be well settled at this point, the support is there.
https://www.morphoice.com/plugins

That said, the numbers still tell the same story: Linux accounts for under 1% of downloads across the board. Which brings me to a genuine question rather than a complaint, is that just the real size of the audience for this kind of thing, or am I failing to reach it? If there are places I should be posting Linux-native audio plugin releases, communities, forums, subreddits, mailing lists, I'd honestly welcome the pointers. I'd rather find out I've been fishing in the wrong pond than assume the pond is empty.

Advertising on the following sites will help get your product seen: LinuxMusicians.com, the Ardour forum, and the Linux section of the Reaper forums.

[Tiles]

Quick update for this thread: all my most prominent plugins now have Linux builds available. So the "he doesn't support Linux" concern should be well settled at this point, the support is there.
https://www.morphoice.com/plugins

That said, the numbers still tell the same story: Linux accounts for under 1% of downloads across the board. Which brings me to a genuine question rather than a complaint, is that just the real size of the audience for this kind of thing, or am I failing to reach it? If there are places I should be posting Linux-native audio plugin releases, communities, forums, subreddits, mailing lists, I'd honestly welcome the pointers. I'd rather find out I've been fishing in the wrong pond than assume the pond is empty.

Well, Linux audio is simply a niche within a niche. There are certainly Linux users interested in commercial plugins, but compared to Windows and macOS it's still a very small market. At some point you'll probably know most of your customers by name.

One thing that's also worth keeping in mind is that many Linux users won't actually use the native Linux build. They'll just run the Windows version through Wine and Yabridge because that's already part of their workflow. Even if you counted those users as "Linux users," though, I wouldn't expect it to fundamentally change the picture. Maybe you'd end up at 2% instead of 1%, but not much beyond that.

[ruralaudio]

Quick update for this thread: all my most prominent plugins now have Linux builds available. So the "he doesn't support Linux" concern should be well settled at this point, the support is there.
https://www.morphoice.com/plugins

That said, the numbers still tell the same story: Linux accounts for under 1% of downloads across the board. Which brings me to a genuine question rather than a complaint, is that just the real size of the audience for this kind of thing, or am I failing to reach it? If there are places I should be posting Linux-native audio plugin releases, communities, forums, subreddits, mailing lists, I'd honestly welcome the pointers. I'd rather find out I've been fishing in the wrong pond than assume the pond is empty.

Thanks for sharing this and being open about it Morphoice, it’s really nice to see, and at least for me a big plus! If I was looking for synths, you would be on top of my list by now.

Just to let you know: I tried one of your synths in beta and stumbled into some problems, tried to figure out where to get in touch with you and ended up reaching out on Facebook, where I never heard back. So I just assumed you were not interested in contact, being visible here definitely changed that for me.

And, yes, I do believe you are fishing in the wrong pond here at KVR (with all respect to the forum). The most active place I have found for #LinuxAudio is Mastodon, where the people use the #LinuxAudio hashtag and share experiences that way. Taking part in the conversation there - like you do here - could over time create a bigger Linux audience.

You could also consider reaching out to Amadeus from Linuxaudio.dev for an interview, and have a chat about Linux support.

That and linuxdaw.org is my most used sources of information regarding plugins etc…

Hope you can use this info for something, and I wish you the best of luck with your plugins.

[DRMR]

That said, the numbers still tell the same story: Linux accounts for under 1% of downloads across the board. Which brings me to a genuine question rather than a complaint, is that just the real size of the audience for this kind of thing, or am I failing to reach it?

I hadn't heard of your plugin brand before, but it would be good to at least post it to https://linuxdaw.org/

Thnx for supporting Linux and I'll give your plugins a try soon

[DRMR]

One thing that's also worth keeping in mind is that many Linux users won't actually use the native Linux build. They'll just run the Windows version through Wine and Yabridge because that's already part of their workflow.

Sorry, but this I don't get. If there is a native build, why wouldn't you use a native build?

Of course it could be that these users already installed the non-native build before it was released and never converted, but I would assume that any new user would pick the native version (unless they are also using a Windows DAW in wine, but then yabridge is not involved).

[FigBug]

Sorry, but this I don't get. If there is a native build, why wouldn't you use a native build?

WINE provides a more stable binary api than any Linux distro provides. Some times that's the only way a plugin will load if you use a different distro than the plugin author.

https://blog.hiler.eu/win32-the-only-stable-abi/

[ruralaudio]

Sorry, but this I don't get. If there is a native build, why wouldn't you use a native build?

WINE provides a more stable binary api than any Linux distro provides. Some times that's the only way a plugin will load if you use a different distro than the plugin author.

https://blog.hiler.eu/win32-the-only-stable-abi/

After a year of using CachyOS (based on Arch Linux), I have never experienced this problem.

I would install the native linux version any day of the week. Wine/Yabridge is not without quirks, so anyone relying on plugins with this method (which I personally do) is up for some tinkering once in a while.

[audiojunkie]

Sorry, but this I don't get. If there is a native build, why wouldn't you use a native build?

WINE provides a more stable binary api than any Linux distro provides. Some times that's the only way a plugin will load if you use a different distro than the plugin author.

https://blog.hiler.eu/win32-the-only-stable-abi/

I'm not sure who you are trying to fool, or if you are the one being fooled. You are talking about APIs and the article talks about ABIs.

ABIs under linux, follow rules to keep things from breaking. That little blog post you linked to was so one-sided, that it is impossible for anyone to take it seriously. It was written by a frustrated developer, rather than a balanced article, and it was able ABIs, not APIs like you are talking about.

In Linux, "the User-space ABI is treated as sacred." The Linux kernel has a long-standing policy of not breaking userspace:

https://docs.kernel.org/admin-guide/abi.html

In-kernel APIs are intentionally not unchanging, but it doesn't affect the software on almost all cases. These are for Internal kernel functions, Kernel data structures, Driver APIs, and Loadable module interfaces. These can and do change from release to release to allow refactoring, optimization, security fixes, and new features.

https://github.com/torvalds/linux/tree/ ... tation/ABI

The very opposite of what you are saying, is actually true--distributions provide a layer of ABI stability as well. Most ABI stability comes from glibc, libsdc++, openSSL, Qt, GTK, and other userspace libraries. Distributions carefully manage SONAMEs, shared library versioning, symbol versioning, and compatibility packages. When a library ABI must change, distributions usually install a new version right alongside the old one, rather than replacing it outright.

Finally, many important libraries, especially glibc, use symbol versioning. A binary can continue using the older symbol version, even when running against a newer library. This is one of the biggest reasons Linux distributions can upgrade libraries without breaking old applications.

Further, stable kernel ABIs are documented. The stable interfaces are expected to maintain compatibility, while testing interfaces may still evolve. If the distro used stays with the stable interfaces, there should be no problem, even if there is ABI evolution within the testing phases.

And finally, modern atomic/immutable linux versions (like what I use), reduces ABI issues even beyond that, through containers, flatpaks, snaps, appimages, etc. I simply don't have the problems that you describe, and I highly doubt those who use these new "cloud-native" technologies experience these problems either. Most of the dependency stack is packaged and untouchable by ABI issues from the host system's libraries. They are essentially insulated from these problems.

Keep the userspace ABI stable, allow kernel internals to evolve rapidly, and use library versioning plus packaging systems to preserve application compatibility.

This is why a 15 year old userspace program can often still run on a modern Linux system.

[pekbro]

Wine was never enough to get me to commit to linux personally. YMMV
Native support from the likes of Adobe and many others, who are not likley
to support it anytime soon is what it will take. Wont say never though, it
depends entirely on the desktop market.

[audiojunkie]

Wine was never enough to get me to commit to linux personally. YMMV
Native support from the likes of Adobe and many others, who are not likley
to support it anytime soon. Wont say never though, it depends on the desktop
market.

I would be less worried about WINE, if bridging software wasn't necessary. I personally avoid bridges like yabridge, or LinVST3 or Carla. I use WineASIO when I absolutely need to, because it is complete, reliable, and doesn't have to change per WINE version. Native Linux software is the best way to go about it.

EDIT: BTW, WINE now supports Adobe products. They put out a patch a few months ago for it.

[FigBug]

I'm not sure who you are trying to fool, or if you are the one being fooled. You are talking about APIs and the article talks about ABIs.

Sorry, typo, I meant ABI.

And finally, modern atomic/immutable linux versions (like what I use), reduces ABI issues even beyond that, through containers, flatpaks, snaps, appimages, etc. I simply don't have the problems that you describe, and I highly doubt those who use these new "cloud-native" technologies experience these problems either. Most of the dependency stack is packaged and untouchable by ABI issues from the host system's libraries. They are essentially insulated from these problems.

Flatpaks aren't really a solution suitable for end users. They basically end up in a sandbox, and can't load plugins from ~/.vst3 So then you need to end up building your plugin as a Flatpak too... so Flatpak DAWS can only load Flatpak plugins. (Yes, there are things you can do to let the DAW escape the sandbox, but it's non trivia)

[mabian]

...And, if I'm not mistaken, flatpak stuff takes much more disk space.

I'm not too happy about that

- Mario

[audiojunkie]

I'm not sure who you are trying to fool, or if you are the one being fooled. You are talking about APIs and the article talks about ABIs.

Sorry, typo, I meant ABI.

And finally, modern atomic/immutable linux versions (like what I use), reduces ABI issues even beyond that, through containers, flatpaks, snaps, appimages, etc. I simply don't have the problems that you describe, and I highly doubt those who use these new "cloud-native" technologies experience these problems either. Most of the dependency stack is packaged and untouchable by ABI issues from the host system's libraries. They are essentially insulated from these problems.

Flatpaks aren't really a solution suitable for end users. They basically end up in a sandbox, and can't load plugins from ~/.vst3 So then you need to end up building your plugin as a Flatpak too... so Flatpak DAWS can only load Flatpak plugins. (Yes, there are things you can do to let the DAW escape the sandbox, but it's non trivia)

Sorry, no. Flatpaks work just fine for Flatpak'ed DAWs, as long as the plugins can be installed into the Home user's folder, which Flatpaks can read without problems. I still don't use Flatpaks with audio tools, but the old way of scattering plugin files all around in various locations, like lib and such has been done away with (for those that keep up). Most plugins are not installed system-wide these days. The majority of plugins now just use:

~/.lv2
~/.vst3
~/.clap

And even that is starting to change. The modern trend is the XDG base directory specifications. So now, and into the currently known future, plugins are increasingly being placed in XDG-compliant locations such as:

~/.local/share/lv2
~/.local/share/vst3
~/.local/share/clap

Either way, these files are very accessible to Flatpak. Flatpak and the Linux audio ecosystem have largely converged on XDG data directories as the preferred way to expose user-installed plugins to sandboxed applications.

But that's not the point you were making with your original comment. Your original comment was regarding ABIs, which I demonstrated are quite stable.

[audiojunkie]

...And, if I'm not mistaken, flatpak stuff takes much more disk space.

I'm not too happy about that

- Mario

Now this is true. You are basically statically linking libraries that might well exist as different versions for the base OS. It's a trade off. Some don't like it, some don't mind. I use Fedora Silverblue, and it runs flawlessly (yes, I said flawlessly), so I don't mind the tradeoff. I haven't had any problems on Linux in the years since I moved to Fedora.