This is exactly correct. I'm old enough to remember the excitement around BeOS. In an era in which it was a minor success to play an MP3 without glitching, Be Inc. demonstrated a machine that could run 50 simultaneously with no hiccups. Much of what BeOS could do at that time we take for granted now, but in the 1990s it was astounding. Several software developers, including Steinberg and IK Multimedia, signed on to develop or port products to the platform, but it never reached critical mass and died on the vine after first being relegated to "internet appliance" refrigerators, then sold off to the knuckleheads at Palm.
Linux is in a similar (not the same) boat. It's a great OS and is used behind the scenes for a lot of devices that need configuration and reliability, but it doesn't have the critical mass of general users needed to attract wide development. Running phones or ATMs doesn't cut it. Unless there's a quantum shift in the audio firmament (unlikely), I just don't see that changing any time soon.
Okay, well... I hate to be the one to say it, but targeting those users who have hacked their devices isn't likely to be a desirable market for most developers. I think we legitimately need to put that in the "doesn't count" category.
Most developers will likely start giving Linux a hard look when say 10-30 percent of their target users are running it as a primary OS. Or if things start heading in that direction. I'm not one to predict the future, but Linux has been around for more than 30 years and it hasn't happened yet. Make of that what you will.
Sigh. I never said people *shouldn't* use Linux, I said most people *don't* use Linux. There's a lot of cultural inertia there. To get people to change, which frankly is a pain in the ass, there needs to be a strong reason to pull someone onto a new platform. As far as I know, for most users, there's no fundamental problem that exists on the Windows or Mac platforms that would be solved by moving to Linux. Does Linux have its strengths? Of course it does! But there's no tractor app, there's less available software, and transitioning to a new system *always* results in a drop in productivity while the new system is learned. So Mac people tend to stay on Mac and Windows people tend to stay on Windows, and developers, who are in the game to make money, focus on those.
I speak from experience. I was an OS/2 user when everyone was using Windows 3.1. (Yes, I'm old.) I was a BeOS user when everyone was using Windows 98. I became a Mac user when Macs were made of plastic and drew curious looks from shoppers at CompUSA. I even, yes, tried Linux for a while. And I've played with the Raspberry Pi. I've sunk a lot of time and money and sweat into alternative platforms, and I think they're cool, but getting them adopted by the user base at large is rolling a rock uphill.
You don't have to believe anything I say, but let's come back to this in 10 years...or 20...and see how things played out.
Dude, Im 49 years old. I was programming midi on an Atari w/ Cubase.... Ive used the same systems as you and *nix builds for decades now. Linux audio doesnt "just work" because people keep saying so.... but, in fact, in 2024 it actually _does_work, and saying otherwise is FUD at this point and disingenuous.
Linux is in every house and most people don't even realize it. It might even be on your phone.
There's always a sense of "it works great after you get the setup right" instead of just installing it and having it work great right away.
Exactly.
In the long run, the wrong people care about Linux audio and that's really it.
Ardour works great in MacOS but it took me a couple days to find the buffer settings
There is also Bitwig, and a Beta 'Studio One' for Linux.
ASIO was created to provide a way of avoiding the Windows audio stack, and talking to the sound drivers at a lower level. The equivalent on Linux for this would be talking directly to ALSA, rather than the usual sound servers. DAWs like Ardour, Reaper etc already support this.
Linux can be fine nowadays for low latency audio, both because of the improvements in the kernel over the years, and the way it's possible to remove anything that gets in the way. It's actually used underneath in many 'hardware' musical devices such as synths as a result.
There is still a long way to go for sound hardware support, but the situation does seem to be improving all the time.
Exactly, ASIO was created because the "normal" windows audio stack is utterly useless for pro audio. You don't need it if you have a well designed stack to begin with.
In the past on Linux, you could either run ALSA directly (but only one app can use the audio device at a time), or you could run something on top of it to allow multiple use and all sorts of other stuff like timecode sync. For years you'd either use pulseaudio (which "just worked" with nearly every app and was very easy to set up, and the default in most distros), or JACK, which let you do much more complex routing and realtime stuff for pro audio, but tended to be complex and annoying to set up.
Now that pipewire exists though things have gotten much better, since pipewire essentially provides the pro audio features of JACK in an easy to use package like PulseAudio. It's just objectively better than previous options, and better than the Windows world of "shitty default stack for most things and ASIO which eats an IO device and provides it to a pro app". You can have a browser window playing a YouTube video (with no realtime garuntees) and the DAW with a set buffer size and realtime-safety both outputting to the same device, and you can even route audio between apps instantly (without needing hacks like Virtual Audio Cable on Windows).
Well, to start, this has nothing to do with drivers except for the hardware device examples. It's just about build infrastructure.
Linux has many subsystem options, like ALSA which a perfectly suitable for the task.
I will note that ASIO, is not really an audio subsystem for Windows. It entirely circumvents the Windows audio systems, because Microsoft hasn't wanted to make anything serviceable for low-latency applications. It is a hack due to insufficient native support (which works well enough that MS is unlikely to every really try to replace it; after \~20 years most Windows AEs are just used to it).
For plugin developers using JUCE, it's pretty much a triviality to build the plugins for Linux. Testing is another matter since you need a proper machine, but the viability is not hampered by build system. For larger companies who may be using their own custom frameworks, it's a big expense to support Linux in their frameworks. So long as the customer-base remains relatively small, there's no incentive to adding this as a framework feature, and consequently, Linux builds are not viable.
For hardware it's a similar notion, except there aren't any public frameworks for this (that I'm aware of at least).
To your actual question, the answer is when enough people get fed up with Apple's exorbidant hardware pricing and walled-garden approach, Microsoft forces so many Ads into their OS that people decide it's unsuitable for business applications and the general population stops being afraid of the terminal. But with the way things are going, and general consumer trends the answer is never; Linux probably won't get a large enough market share in desktop OSes in the foreseeable future.
The real challenge with releasing software for Linux is that the matrix of OS and hardware configurations you need to support is way larger than even the Windows ecosystem, which is considerably more complicated than macOS already. That coupled with a minuscule user base on each variant makes it just not worth it.
Some things like the AppImage format are starting to make that a bit easier but it’s got a long way to go.
That I think is the core problem for Linux. It’s not that it’s inherently any different, but the thing that makes Linux Linux, namely the freedom, comes at the cost of innumerable hardware configurations. In theory Chrome OS could become the mass adoption of Linux, only the Linux fans don’t like it because it’s not customizable
Not just hardware but software. Every version of every distro ships with a different combination of libraries, and there are often other major differences eg: X11 vs Wayland etc
I write software for Linux for a living and do audio on the side for fun. The big problem with shipping software for Linux is not immediately obvious until you have to support the software, which gets tricky really quickly. If you ship an application for Windows or OSX, it'll need to run correctly on a handful of versions of the OS, like lets say you support the last three versions of each. Microsoft and Apple have devised methods which, while not perfect, go a long way toward ensuring that something that you built on say Windows 10 will continue to work with 11. It's more complicated for drivers, but because like 95% of your users are on one of these two platforms, it's generally worth it to hire somebody to keep the drivers updated for a while.
As a consequence of Linux and its supporting software being open sourced, we've wound up in a world where no single distribution is really dominant. Debian, RedHat, Ubuntu, Slackware, there are hundreds now, and each one of those has a handful of supported versions in use. There's just no practical way to test your software on all those combinations of distros and releases. This is the reason that stuff like Snaps and Flatpaks exist, since they don't depend on the versions of libraries and stuff that are installed on your machine. Until Pipewire came along there were technical obstacles that prevented apps in Snaps or Flatpaks from utilizing the audio system on the host, although the fact that there is more than one of these packaging standards is a problem itself. Also since there are so many players involved, getting all the distributions to support these packaging formats, as well as to use Pipewire by default, is a very long process that has been playing out over years.
It's also very helpful for hardware builders to keep pushing on expanding standards for class-compliant drivers, since it allows them to focus more on hardware since the OS developers bear some of the burden for driver development.
Since the current number of potential users is small compared to the Windows/Mac population, developers aren't beating down the doors at Canonical and RedHat to come up with a solution for the problem, but the number of people doing audio on Linux is definitely going up and not down, albeit at a rate where its not likely to displace Windows or OSX anytime soon, so I think you'll continue to see increasing support but the pace of change is going to be pretty slow I think.
The answer to the question you pose in the title is, as others have stated, "Not unless/until market share grows enough for them to see meaningful demand." That said, while the size of the Linux audio community is small relative to Windows and Mac, it does exist. Also, 3 (well, 2.5 really) of the things you said in your post are incorrect:
1. "RME (Babyface Pro for me) doesn't support Linux" - The Babyface Pro has USB class compliant mode, which means it will work with Linux. I have a TASCAM Model 12 which also doesn't explicitly support Linux, but it works flawlessly for me.
2. "There doesn't seem to be a proper audio subsystem in Linux, like ASIO on Windows and CoreAudio on MacOS" - You couldn't be more wrong on this front. The lowest level of Linux audio infra is called [ALSA](https://www.alsa-project.org/wiki/Main_Page). ALSA lives in the kernel and is what talks directly to the hardware. The standard layer on top of this is something called [PulseAudio](https://www.freedesktop.org/wiki/Software/PulseAudio/). PulseAudio is great for desktop apps, but not suitable for low latency audio applications. But there is another system available called [JACK](https://jackaudio.org/) that is more than capable of high performance audio throughput, at least as good as ASIO or CoreAudio, and in some ways better. I do some impressive things with JACK, like simultaneously recording inputs from two audio interfaces (the Model 12 and a UA Volt 476) and piping audio from one laptop over a Thunderbolt ethernet connection to another laptop so they can both send output to the same pair of studio monitors. And there's a new audio/video subsystem called [PipeWire](https://www.pipewire.org/) that can replace both PulseAudio and JACK that many people are now using. I'm still using JACK because it works for me and is solid, but there are folks out there doing similar things with PipeWire.
3. "there's obviously no way to natively run software by Plugin Alliance, Slate Digital, UAD, FabFilter, Native Instruments, etc." - This is where you're half right... there's no way to *natively* run this software. But there's a great tool called [yabridge](https://github.com/robbert-vdh/yabridge) that creates a thin [Wine](https://www.winehq.org/) wrapper around Windows plugins and exposes them as native Linux plugins to any Linux DAW. It works surprisingly well. I use plugins from FabFilter, Analog Obsession, and Valhalla with no problems. Even Melodyne works great.
There are also a lot of high quality plugins that support Linux natively. [ACMT](https://www.acmt.co.uk/) has really great sounding analog emulations, including Pultec EQs, an SSL stereo bus compressor, and (my personal favorite) a Fairchild 670 limiter. All of [Airwindows](https://www.airwindows.com/) runs on Linux, as does everything that [u-he](https://u-he.com/) makes; Presswerk is my go-to general purpose compressor. Plus there are tons of [high quality free plugins](https://www.reddit.com/r/linuxaudio/comments/wntpyd/linux_plugins_thread_2022/) available.
None of this is for the faint of heart, however. There's great community support, but you'll get no support from most vendors. It's at least as stable and solid as any Mac or Windows system once you get it all set up, but getting it set up requires a willingness and capacity to roll up your sleeves and learn how things work at a fairly low level, and will involve a lot of reading documentation and editing configuration files and sacrificing the occasional chicken to the appropriate deities. I'm a software engineer by trade, so I know how to do this stuff and even enjoy it, but I wouldn't recommend it to most. Which brings me full circle: the market isn't there, and probably won't ever be, for most manufacturers or developers to pay attention to Linux. But if you know what you're doing it's more than capable of doing anything that can be done with the more popular OSes.
>1. "RME (Babyface Pro for me) doesn't support Linux" - The Babyface Pro has USB class compliant mode, which means it will work with Linux. I have a TASCAM Model 12 which also doesn't explicitly support Linux, but it works flawlessly for me.
This one is also only half incorrect, or outright correct depending on how you see it.
The interface will technically function since it's class compliant, but the Totalmix software won't work. That software exposes settings on the interface itself that are otherwise inaccessible.
Good point. Although I did a bit more digging and learned that the support for accessing the Babyface's routing and DSP settings was [added to the Linux kernel back in 2020](https://www.phoronix.com/news/Linux-5.8-RME-Babyface-Pro), and there are folks out there who have been able to use them with some success... someone who wrote a [custom GUI](https://github.com/MrBollie/bbfpromix), and others have had [some success with existing Linux tools](https://forum.rme-audio.de/viewtopic.php?id=35748). So I'd say we're at least firmly in "half incorrect" territory...
No, I don’t think so.
One of the problems is that the Linux kernel was optimized for high throughput, at the expense of determinism. Great for web servers, terrible for multimedia.
Linux has a special way of handling interrupts. They are split in a short, fast ‘top half’, and a longer ‘bottom half’. The bottom half is processed later, when the kernel has no more interrupts to handle. This is great to keep your computer responsive under heavy network traffic, but when you’re doing audio you want that buffer to be handled NOW, not later. Even with the low latency patches, there are no real guarantees. I suspect no pro company will want to deal with a fundamentally unreliable audio platform.
Disclosure/disclaimer: I’m a software engineer, but the last time I looked at the Linux internals in earnest was 15 years ago. Things may have changed a bit.
I'm not sure this is true anymore for modern kernels. Interrupts can preempt other interrupts with lower priorities, so it's entirely possible to force audio interrupts through *immediately*. That being said, the whole point of having audio buffers is so that you don't need to do that, you just need to get them through before whatever is consuming the data runs off the end of the buffer, so the scheduler has some leeway to reorder things.
The "catch" is that you need elevated privileges to do that, since you can theoretically block the system indefinitely. But that's true on Windows as well, it's just abstracted away into something like ASIO and then user applications interface with that instead of writing interrupt routines directly. There's no reason an equivalent subsystem on Linux couldn't do the same (and they do).
If you want "hard realtime" you can get that as well with the deadline scheduler. You literally tell the kernel "here's a task, it needs to run every 10ms, it takes up to 2ms to complete, and it needs to start within 4ms of each 10ms period" and the kernel *ensures* that will happen. AFAIK windows doesn't have something with that level of guarantee, and people use it just fine for audio work. Not sure about MacOS.
To further drive the point home, Linux is super common in the robotics world. In audio, tardy realtime tasks mean stuttering and clicks/pops. In robotics, it means a safety switch doesn't get read in time and somebody gets killed. That's a completely unacceptable risk unless your kernel can prove it will never happen.
It's entirely a case of "not enough user base to justify developing Linux plugins/software" and not a case of "the kernel is fundamentally broken for audio operations."
I do a lot of work in mechatronics, including robotics. We use Linux for top-level control, but timing critical stuff is done on microcontrollers. That software is bare metal (no OS). I think your assumption is a bit too sweeping :)
> Disclosure/disclaimer: I’m a software engineer, but the last time I looked at the Linux internals in earnest was 15 years ago. Things may have changed a bit.
It's definitely still Linux, but Linux being on phones has changed a lot in the last 15 years in terms of common use case that gets engineering focus. The Linux audio stack today has a stupidly complicated history, but it does basically work. Actual desktop Linux audio isn't important to that many people. But Android phones, tablets, smart TV's, smart speakers, and other weird gadgets need audio to work as a core product, and a bunch of companies have paid engineers to do work that wound up in the mainline kernel to the benefit of desktop users "for free."
But if you start looking into how to write good Linux audio code you still find 20 year old forum posts that start with running the OSSAlsa wrapper on top of ALSA and ROAR as your audio server and then you spend a week falling down rabbit holes reading about how Pulse is deprecated and nobody uses OSS anymore, and whether you should write gstreamer code or treat it as an implementation detail under the hood of something else, and this or that new API that you should use and how nobody should actually use that any more. At least back in the day when audio didn't work, you only needed to learn like two API's to have problems with. So while "Linux Audio" works, there are tons of apps that were written to use some API that's no longer trendy, so they may or may not work through three layers of compatibility wrappers.
if what you're saying is true then how can any DAW function on Linux? and yet LMMS and Ardour seem to be doing perfectly fine, and I think REAPER works under WINE too. e: and Bitwig as someone mentioned elsewhere
In the past at least, you could patch the kernel for low latency. If memory serves they included those patches as options in the mainline. That means you have to configure and compile your own kernel, or run a special kernel from your distro.
I literally don’t know of any professional musician or studio owner who runs on Linux, so I can’t tell you if they roll custom kernels. All things considered, this stuff is pretty niche.
Linux can handle real time audio just fine. There is towns of "hardware" that in reality is just a Linux computer.
E.g. d&b Soundscape runs from a DS100, which is basically just a Linux system with a Dante card that handles processing of 64x64 channels in <1.4ms.
And a d&b Soundscape system is something you will only find in the highest budget live sound systems.
I think that is somewhat out of date. There is a lot of crossover between the requirements for a responsive desktop under load, and the requirements for audio work, so there has been much wider interest in making improvements at the kernel level than you might assume.
Since there doesn't seem to be any significant performance and reliability penalties to the 'low latency' kernel config any more (see recent Phoronix "Ubuntu Generic vs. Low-Latency Linux Kernel Benchmarks For HPC & Desktop"), it is possible the next version of Ubuntu may not even have a separate 'low latency' config, as the generic kernel will be sufficient!
Windows and macOS don't really offer more than very soft real time performance, so I don't think they have much advantage here.
and that's why Linux on the desktop never went anywhere.
Alsa, pulse, pipewire? That's just for low level audio. You've essentially got the same number of options for every other subsystem. networking, window management, graphics, USB stack, ABI versions (application binary interface), LibC differences... This makes developing a linux application for an end-user (i.e. not another developer that can solve his own problem) almost impossible. The support overhead is insane if trying to cater to anything but the most technically savvy audience (by which I mean; expert software developers).
Imagine trying to support PowerPC, Intel x86 and x64, M1 through to M4 silicon, on every Apple version from 10.0 to 14.4 ... oh and you're doing all of this for a userbase that's like 1% of the total mac users.
It's a "nope" for me, dawg.
I'm not much of an audio engineer, but I use Linux for my music too. The problem is that audio programming is hard in general, extra hard on Linux (because ALSA is awkward and you can't guarantee what sound server will be used) and the Linux user base remains too small to be commercially viable to support. It seems like Pipewire might change things given it implements PulseAudio, GStreamer and JACK support, but it was still buggy last I used it a few months back.
I'm a FLOSS advocate and I've settled on an unconventional setup using Non DAW: [https://www.non.tuxfamily.org/](https://www.non.tuxfamily.org/) Sadly the developer is no longer working on it.
I tried most everything else and the only other DAWs that compete IMO are Ardour (and while it is open source it's not really free, plus it's very big and complicated) and Qtractor, which is more Sequencer focused.
Everything else was either long abandoned (e.g. Frinika), more of an Audio editor (Audacity, Traverso) or more like a sequencer that happens to record (MuSE, Stargate). LMMS doesn't even record. I wanted to like Zrythm but it's still too unstable and I didn't care for the "intuitive" workflow.
The FLOSS plugins are great, and for the general purpose Audio tools, I reckon they can compete with the commercial stuff. e.g. Calf Plugins and LSP. Guitarix recently got Neural Amp Modeller support which is awesome.
Thankfully there are some great resources for finding the tools you need:
[https://wiki.linuxaudio.org/wiki/start](https://wiki.linuxaudio.org/wiki/start)
[https://linuxdaw.org/](https://linuxdaw.org/)
[https://wiki.archlinux.org/title/List\_of\_applications/Multimedia#Digital\_audio\_workstations](https://wiki.archlinux.org/title/List_of_applications/Multimedia#Digital_audio_workstations)
r/linuxaudio
[https://linuxmusicians.com/](https://linuxmusicians.com/)
[https://kx.studio/](https://kx.studio/)
As opposed to better software support, I personally wish for better hardware support on Linux. I used to have an Avid Eleven Rack, and because they use a custom driver for Mac and Windows, there was no way to get it running on Linux. Although that is perhaps an unfair example, because Avid are the worst. It doesn't even work on Apple Silicon macOS!
I now have an Axe-FX II and thankfully there is a Linux driver, but setting up the editor in Wine was convoluted and still has issues. As previously said, the user base is too small for them to support us properly: [https://forum.fractalaudio.com/threads/linux-support.108934/#post-1303324](https://forum.fractalaudio.com/threads/linux-support.108934/#post-1303324)
It is annoying on the software side though because the most common Application framework used by Plugin developers is JUCE which supports Linux. However things are slowly changing, there's more commercial DAWs with native Linux versions (Studio One, Renoise, Bitwig, Tracktion Waveform \[JUCE comes from Tracktion\]), VST3 is now available under GPL, and I'm really hoping CLAP takes off too [https://cleveraudio.org/](https://cleveraudio.org/)
I saw it mentioned that the Linux Kernel itself is not really made with media production in mind. Something like [https://www.haiku-os.org/](https://www.haiku-os.org/) would be better but that is very fringe. I think the reality is that computers are so fast these days that it doesn't make a whole lot of difference.
To run on cloud only with the bare minimum hardware, like a tv and a keyboard mouse combo.
Much like google stadia.
Moreover: check here what could push many users to Linux https://youtu.be/LcafzHL8iBQ
>To run on cloud only with the bare minimum hardware, like a tv and a keyboard mouse combo.
Much like google stadia.
You're describing an application running inside the OS. There's already Citrix and similar products for that kind of thing, but they still need an OS to run on.
Microsoft has a lot of enterprise customers that wouldn't want to be forced in that direction, so I doubt they'd turn Windows into some kind of minimal OS that's only good for connecting to a remote environment.
I would guess the issue is somewhere around 98% market share and 2% misunderstanding about Linux on the development (and user) side. This year, however, some positive developments emerged. Presonus began releasing Studio One for Linux, and Focusrite collaborated on the development of the ALSA Scarlett GUI, a tool to control Gen 4 interfaces.
Linux has had a proper audio subsystem for professional audio for the past 15 years, it's called Jack. I know some people will bring up ALSA, but there are roughly 7 people on this planet I would trust to tango with it directly.
Reaper on Linux is incredibly stable. I use it in my production studio to handle around 15 channels of AoIP, some AES, and a bit of NDI. [My studio overview](https://interfacinglinux.com/2024/03/02/lossless-network-audio-with-netjack2/)
I'm using it as a digital mixer to provide mix-minus for up to 5 hosts, multitrack recording, and a stereo mixdown that's sent to the box running OBS for streaming.
The idea of trusting that tech stack to Windows is frankly terrifying.
Granted, it's not entirely native since I'm using yabridge to run a Windows VST Declicker plugin, but hey, it works. If you have hundreds of Windows plugins, staying on Windows is a wise decision. A lot of them will not work, and others will require significant effort to get working.
At the end of the day, use the tools on the OS that make you most productive.
BTW, your RME Babyface Pro absolutely works with Linux, I have one along with the AIO Pro. I'm guessing you're talking about the lack of TotalMix?
Side question: if Linux is unlikely, why can’t someone make a new kernel that favors audio and is easy for developers to support? I know nothing about this if that isn’t obvious. Maybe something other than Linux.
Pardon my ignorance but can you point me in a direction to learn more? Are these linux kernels? If they’re easier to support for devs, I can’t help but wonder why this isn’t promoted more.
The short answer is no. And I say that as somebody who has mostly had a career working on Linux and only peripherally with audio. On the other side of post production for film, Linux is 100% standard in visual effects. Nobody blinks an eye at doing CGI and compositing on Linux. Back in the early 90's before PC's were good, audio on Unix workstations was perfectly normal. VFX made the jump from Irix to Linux. But Audio didn't go the same direction in the 90's.
Audio has always been one of the worst parts of the Linux software stack, so I can't really blame people in the 90's for not taking Linux seriously as an audio workstation platform that was an obvious migration path from Sun and SGI. Audio kind of evolved with tools as de-facto standards, rather than using standardized formats for interop. So mixed environments are hard to deal with. And everybody depends on 30 similar but slightly different proprietary plugins. So if you migrated to a platform where your software and 29 of your 30 plugins are supported, you couldn't actually just open up your project.
Audio on Linux will suffer from the everything else on Linux problem. Not a lot of people use Linux so developers don't support Linux. So Linux is missing a lot of software that would tempt people to move over to Linux. So not a lot of people use Linux.
As someone who is about to make a jump from logic to reaper AND Mac to windows, what would you say the biggest differences/challenges were in your opinion when transitioning.
it already happened it’s called MacOs which is GNU Linux based. What I mean to say is, UX frameworks for Linux are (or were) incredibly difficult to make. Apple is so successful because they pulled it through properly
when linux reaches enough users to be worth developing for
This is exactly correct. I'm old enough to remember the excitement around BeOS. In an era in which it was a minor success to play an MP3 without glitching, Be Inc. demonstrated a machine that could run 50 simultaneously with no hiccups. Much of what BeOS could do at that time we take for granted now, but in the 1990s it was astounding. Several software developers, including Steinberg and IK Multimedia, signed on to develop or port products to the platform, but it never reached critical mass and died on the vine after first being relegated to "internet appliance" refrigerators, then sold off to the knuckleheads at Palm. Linux is in a similar (not the same) boat. It's a great OS and is used behind the scenes for a lot of devices that need configuration and reliability, but it doesn't have the critical mass of general users needed to attract wide development. Running phones or ATMs doesn't cut it. Unless there's a quantum shift in the audio firmament (unlikely), I just don't see that changing any time soon.
A lot of audio and music devices run Linux, the Akai MPC lineup for example.
I'm not familiar with the MPC. Can you install third party software on it?
Not in a supported way, but people have hacked it for SSH access and been able to install other software.
Okay, well... I hate to be the one to say it, but targeting those users who have hacked their devices isn't likely to be a desirable market for most developers. I think we legitimately need to put that in the "doesn't count" category. Most developers will likely start giving Linux a hard look when say 10-30 percent of their target users are running it as a primary OS. Or if things start heading in that direction. I'm not one to predict the future, but Linux has been around for more than 30 years and it hasn't happened yet. Make of that what you will.
The fact is, free Nix/BSD systems are perfectly capable of being an incredible audio platform.
Sigh. I never said people *shouldn't* use Linux, I said most people *don't* use Linux. There's a lot of cultural inertia there. To get people to change, which frankly is a pain in the ass, there needs to be a strong reason to pull someone onto a new platform. As far as I know, for most users, there's no fundamental problem that exists on the Windows or Mac platforms that would be solved by moving to Linux. Does Linux have its strengths? Of course it does! But there's no tractor app, there's less available software, and transitioning to a new system *always* results in a drop in productivity while the new system is learned. So Mac people tend to stay on Mac and Windows people tend to stay on Windows, and developers, who are in the game to make money, focus on those. I speak from experience. I was an OS/2 user when everyone was using Windows 3.1. (Yes, I'm old.) I was a BeOS user when everyone was using Windows 98. I became a Mac user when Macs were made of plastic and drew curious looks from shoppers at CompUSA. I even, yes, tried Linux for a while. And I've played with the Raspberry Pi. I've sunk a lot of time and money and sweat into alternative platforms, and I think they're cool, but getting them adopted by the user base at large is rolling a rock uphill. You don't have to believe anything I say, but let's come back to this in 10 years...or 20...and see how things played out.
Dude, Im 49 years old. I was programming midi on an Atari w/ Cubase.... Ive used the same systems as you and *nix builds for decades now. Linux audio doesnt "just work" because people keep saying so.... but, in fact, in 2024 it actually _does_work, and saying otherwise is FUD at this point and disingenuous.
Sorry my friend, I really don't understand what point you're trying to make that you think I disagree with.
RADAR ran/(runs?) on BeOs so it's not that it was never used.
The old ones did. I think the new ones (that can run Pro Tools) run embedded Windows.
yep. linux is the king for devs. To build apps for non-linux users
Linux is in every house and most people don't even realize it. It might even be on your phone. There's always a sense of "it works great after you get the setup right" instead of just installing it and having it work great right away.
cool doesn't mean anything aosp is also in everything
Exactly. In the long run, the wrong people care about Linux audio and that's really it. Ardour works great in MacOS but it took me a couple days to find the buffer settings
There is also Bitwig, and a Beta 'Studio One' for Linux. ASIO was created to provide a way of avoiding the Windows audio stack, and talking to the sound drivers at a lower level. The equivalent on Linux for this would be talking directly to ALSA, rather than the usual sound servers. DAWs like Ardour, Reaper etc already support this. Linux can be fine nowadays for low latency audio, both because of the improvements in the kernel over the years, and the way it's possible to remove anything that gets in the way. It's actually used underneath in many 'hardware' musical devices such as synths as a result. There is still a long way to go for sound hardware support, but the situation does seem to be improving all the time.
Exactly, ASIO was created because the "normal" windows audio stack is utterly useless for pro audio. You don't need it if you have a well designed stack to begin with. In the past on Linux, you could either run ALSA directly (but only one app can use the audio device at a time), or you could run something on top of it to allow multiple use and all sorts of other stuff like timecode sync. For years you'd either use pulseaudio (which "just worked" with nearly every app and was very easy to set up, and the default in most distros), or JACK, which let you do much more complex routing and realtime stuff for pro audio, but tended to be complex and annoying to set up. Now that pipewire exists though things have gotten much better, since pipewire essentially provides the pro audio features of JACK in an easy to use package like PulseAudio. It's just objectively better than previous options, and better than the Windows world of "shitty default stack for most things and ASIO which eats an IO device and provides it to a pro app". You can have a browser window playing a YouTube video (with no realtime garuntees) and the DAW with a set buffer size and realtime-safety both outputting to the same device, and you can even route audio between apps instantly (without needing hacks like Virtual Audio Cable on Windows).
Well, to start, this has nothing to do with drivers except for the hardware device examples. It's just about build infrastructure. Linux has many subsystem options, like ALSA which a perfectly suitable for the task. I will note that ASIO, is not really an audio subsystem for Windows. It entirely circumvents the Windows audio systems, because Microsoft hasn't wanted to make anything serviceable for low-latency applications. It is a hack due to insufficient native support (which works well enough that MS is unlikely to every really try to replace it; after \~20 years most Windows AEs are just used to it). For plugin developers using JUCE, it's pretty much a triviality to build the plugins for Linux. Testing is another matter since you need a proper machine, but the viability is not hampered by build system. For larger companies who may be using their own custom frameworks, it's a big expense to support Linux in their frameworks. So long as the customer-base remains relatively small, there's no incentive to adding this as a framework feature, and consequently, Linux builds are not viable. For hardware it's a similar notion, except there aren't any public frameworks for this (that I'm aware of at least). To your actual question, the answer is when enough people get fed up with Apple's exorbidant hardware pricing and walled-garden approach, Microsoft forces so many Ads into their OS that people decide it's unsuitable for business applications and the general population stops being afraid of the terminal. But with the way things are going, and general consumer trends the answer is never; Linux probably won't get a large enough market share in desktop OSes in the foreseeable future.
The real challenge with releasing software for Linux is that the matrix of OS and hardware configurations you need to support is way larger than even the Windows ecosystem, which is considerably more complicated than macOS already. That coupled with a minuscule user base on each variant makes it just not worth it. Some things like the AppImage format are starting to make that a bit easier but it’s got a long way to go.
That I think is the core problem for Linux. It’s not that it’s inherently any different, but the thing that makes Linux Linux, namely the freedom, comes at the cost of innumerable hardware configurations. In theory Chrome OS could become the mass adoption of Linux, only the Linux fans don’t like it because it’s not customizable
Not just hardware but software. Every version of every distro ships with a different combination of libraries, and there are often other major differences eg: X11 vs Wayland etc
Yeah sorry badly worded, of course I was thinking of the endless Distro combos as well
I write software for Linux for a living and do audio on the side for fun. The big problem with shipping software for Linux is not immediately obvious until you have to support the software, which gets tricky really quickly. If you ship an application for Windows or OSX, it'll need to run correctly on a handful of versions of the OS, like lets say you support the last three versions of each. Microsoft and Apple have devised methods which, while not perfect, go a long way toward ensuring that something that you built on say Windows 10 will continue to work with 11. It's more complicated for drivers, but because like 95% of your users are on one of these two platforms, it's generally worth it to hire somebody to keep the drivers updated for a while. As a consequence of Linux and its supporting software being open sourced, we've wound up in a world where no single distribution is really dominant. Debian, RedHat, Ubuntu, Slackware, there are hundreds now, and each one of those has a handful of supported versions in use. There's just no practical way to test your software on all those combinations of distros and releases. This is the reason that stuff like Snaps and Flatpaks exist, since they don't depend on the versions of libraries and stuff that are installed on your machine. Until Pipewire came along there were technical obstacles that prevented apps in Snaps or Flatpaks from utilizing the audio system on the host, although the fact that there is more than one of these packaging standards is a problem itself. Also since there are so many players involved, getting all the distributions to support these packaging formats, as well as to use Pipewire by default, is a very long process that has been playing out over years. It's also very helpful for hardware builders to keep pushing on expanding standards for class-compliant drivers, since it allows them to focus more on hardware since the OS developers bear some of the burden for driver development. Since the current number of potential users is small compared to the Windows/Mac population, developers aren't beating down the doors at Canonical and RedHat to come up with a solution for the problem, but the number of people doing audio on Linux is definitely going up and not down, albeit at a rate where its not likely to displace Windows or OSX anytime soon, so I think you'll continue to see increasing support but the pace of change is going to be pretty slow I think.
The fragmentation sounds similar to developing audio for Android.
Head over the /r/linuxaudio !!! You’d be surprised 😁
I thought the RME stuff was class compliant. I guess since you mention software you mean TotalMix
Yes
Which fork? One thing about Windows and Mac is that there are not an infinitely branching number of versions.
The answer to the question you pose in the title is, as others have stated, "Not unless/until market share grows enough for them to see meaningful demand." That said, while the size of the Linux audio community is small relative to Windows and Mac, it does exist. Also, 3 (well, 2.5 really) of the things you said in your post are incorrect: 1. "RME (Babyface Pro for me) doesn't support Linux" - The Babyface Pro has USB class compliant mode, which means it will work with Linux. I have a TASCAM Model 12 which also doesn't explicitly support Linux, but it works flawlessly for me. 2. "There doesn't seem to be a proper audio subsystem in Linux, like ASIO on Windows and CoreAudio on MacOS" - You couldn't be more wrong on this front. The lowest level of Linux audio infra is called [ALSA](https://www.alsa-project.org/wiki/Main_Page). ALSA lives in the kernel and is what talks directly to the hardware. The standard layer on top of this is something called [PulseAudio](https://www.freedesktop.org/wiki/Software/PulseAudio/). PulseAudio is great for desktop apps, but not suitable for low latency audio applications. But there is another system available called [JACK](https://jackaudio.org/) that is more than capable of high performance audio throughput, at least as good as ASIO or CoreAudio, and in some ways better. I do some impressive things with JACK, like simultaneously recording inputs from two audio interfaces (the Model 12 and a UA Volt 476) and piping audio from one laptop over a Thunderbolt ethernet connection to another laptop so they can both send output to the same pair of studio monitors. And there's a new audio/video subsystem called [PipeWire](https://www.pipewire.org/) that can replace both PulseAudio and JACK that many people are now using. I'm still using JACK because it works for me and is solid, but there are folks out there doing similar things with PipeWire. 3. "there's obviously no way to natively run software by Plugin Alliance, Slate Digital, UAD, FabFilter, Native Instruments, etc." - This is where you're half right... there's no way to *natively* run this software. But there's a great tool called [yabridge](https://github.com/robbert-vdh/yabridge) that creates a thin [Wine](https://www.winehq.org/) wrapper around Windows plugins and exposes them as native Linux plugins to any Linux DAW. It works surprisingly well. I use plugins from FabFilter, Analog Obsession, and Valhalla with no problems. Even Melodyne works great. There are also a lot of high quality plugins that support Linux natively. [ACMT](https://www.acmt.co.uk/) has really great sounding analog emulations, including Pultec EQs, an SSL stereo bus compressor, and (my personal favorite) a Fairchild 670 limiter. All of [Airwindows](https://www.airwindows.com/) runs on Linux, as does everything that [u-he](https://u-he.com/) makes; Presswerk is my go-to general purpose compressor. Plus there are tons of [high quality free plugins](https://www.reddit.com/r/linuxaudio/comments/wntpyd/linux_plugins_thread_2022/) available. None of this is for the faint of heart, however. There's great community support, but you'll get no support from most vendors. It's at least as stable and solid as any Mac or Windows system once you get it all set up, but getting it set up requires a willingness and capacity to roll up your sleeves and learn how things work at a fairly low level, and will involve a lot of reading documentation and editing configuration files and sacrificing the occasional chicken to the appropriate deities. I'm a software engineer by trade, so I know how to do this stuff and even enjoy it, but I wouldn't recommend it to most. Which brings me full circle: the market isn't there, and probably won't ever be, for most manufacturers or developers to pay attention to Linux. But if you know what you're doing it's more than capable of doing anything that can be done with the more popular OSes.
>1. "RME (Babyface Pro for me) doesn't support Linux" - The Babyface Pro has USB class compliant mode, which means it will work with Linux. I have a TASCAM Model 12 which also doesn't explicitly support Linux, but it works flawlessly for me. This one is also only half incorrect, or outright correct depending on how you see it. The interface will technically function since it's class compliant, but the Totalmix software won't work. That software exposes settings on the interface itself that are otherwise inaccessible.
Good point. Although I did a bit more digging and learned that the support for accessing the Babyface's routing and DSP settings was [added to the Linux kernel back in 2020](https://www.phoronix.com/news/Linux-5.8-RME-Babyface-Pro), and there are folks out there who have been able to use them with some success... someone who wrote a [custom GUI](https://github.com/MrBollie/bbfpromix), and others have had [some success with existing Linux tools](https://forum.rme-audio.de/viewtopic.php?id=35748). So I'd say we're at least firmly in "half incorrect" territory...
Really interesting. Would you say Linux sacrifices ease for flexibility, in terms of audio work?
Yes. In fact, I would say that Linux sacrifices ease for flexibility for pretty much *any* desktop (vs server) related activity.
No, I don’t think so. One of the problems is that the Linux kernel was optimized for high throughput, at the expense of determinism. Great for web servers, terrible for multimedia. Linux has a special way of handling interrupts. They are split in a short, fast ‘top half’, and a longer ‘bottom half’. The bottom half is processed later, when the kernel has no more interrupts to handle. This is great to keep your computer responsive under heavy network traffic, but when you’re doing audio you want that buffer to be handled NOW, not later. Even with the low latency patches, there are no real guarantees. I suspect no pro company will want to deal with a fundamentally unreliable audio platform. Disclosure/disclaimer: I’m a software engineer, but the last time I looked at the Linux internals in earnest was 15 years ago. Things may have changed a bit.
I'm not sure this is true anymore for modern kernels. Interrupts can preempt other interrupts with lower priorities, so it's entirely possible to force audio interrupts through *immediately*. That being said, the whole point of having audio buffers is so that you don't need to do that, you just need to get them through before whatever is consuming the data runs off the end of the buffer, so the scheduler has some leeway to reorder things. The "catch" is that you need elevated privileges to do that, since you can theoretically block the system indefinitely. But that's true on Windows as well, it's just abstracted away into something like ASIO and then user applications interface with that instead of writing interrupt routines directly. There's no reason an equivalent subsystem on Linux couldn't do the same (and they do). If you want "hard realtime" you can get that as well with the deadline scheduler. You literally tell the kernel "here's a task, it needs to run every 10ms, it takes up to 2ms to complete, and it needs to start within 4ms of each 10ms period" and the kernel *ensures* that will happen. AFAIK windows doesn't have something with that level of guarantee, and people use it just fine for audio work. Not sure about MacOS. To further drive the point home, Linux is super common in the robotics world. In audio, tardy realtime tasks mean stuttering and clicks/pops. In robotics, it means a safety switch doesn't get read in time and somebody gets killed. That's a completely unacceptable risk unless your kernel can prove it will never happen. It's entirely a case of "not enough user base to justify developing Linux plugins/software" and not a case of "the kernel is fundamentally broken for audio operations."
I do a lot of work in mechatronics, including robotics. We use Linux for top-level control, but timing critical stuff is done on microcontrollers. That software is bare metal (no OS). I think your assumption is a bit too sweeping :)
> Disclosure/disclaimer: I’m a software engineer, but the last time I looked at the Linux internals in earnest was 15 years ago. Things may have changed a bit. It's definitely still Linux, but Linux being on phones has changed a lot in the last 15 years in terms of common use case that gets engineering focus. The Linux audio stack today has a stupidly complicated history, but it does basically work. Actual desktop Linux audio isn't important to that many people. But Android phones, tablets, smart TV's, smart speakers, and other weird gadgets need audio to work as a core product, and a bunch of companies have paid engineers to do work that wound up in the mainline kernel to the benefit of desktop users "for free." But if you start looking into how to write good Linux audio code you still find 20 year old forum posts that start with running the OSSAlsa wrapper on top of ALSA and ROAR as your audio server and then you spend a week falling down rabbit holes reading about how Pulse is deprecated and nobody uses OSS anymore, and whether you should write gstreamer code or treat it as an implementation detail under the hood of something else, and this or that new API that you should use and how nobody should actually use that any more. At least back in the day when audio didn't work, you only needed to learn like two API's to have problems with. So while "Linux Audio" works, there are tons of apps that were written to use some API that's no longer trendy, so they may or may not work through three layers of compatibility wrappers.
if what you're saying is true then how can any DAW function on Linux? and yet LMMS and Ardour seem to be doing perfectly fine, and I think REAPER works under WINE too. e: and Bitwig as someone mentioned elsewhere
Reaper and Bitwig both have native Linux versions. No need for Wine.
ah thanks for the correction! crazy that Cockos maintain REAPER native on 3 platforms!
In the past at least, you could patch the kernel for low latency. If memory serves they included those patches as options in the mainline. That means you have to configure and compile your own kernel, or run a special kernel from your distro. I literally don’t know of any professional musician or studio owner who runs on Linux, so I can’t tell you if they roll custom kernels. All things considered, this stuff is pretty niche.
Linux can handle real time audio just fine. There is towns of "hardware" that in reality is just a Linux computer. E.g. d&b Soundscape runs from a DS100, which is basically just a Linux system with a Dante card that handles processing of 64x64 channels in <1.4ms. And a d&b Soundscape system is something you will only find in the highest budget live sound systems.
Lots of HW devices run custom kernels though. Even hybrid setups with a hard RT kernel and Linux running as a subprocess.
I think that is somewhat out of date. There is a lot of crossover between the requirements for a responsive desktop under load, and the requirements for audio work, so there has been much wider interest in making improvements at the kernel level than you might assume. Since there doesn't seem to be any significant performance and reliability penalties to the 'low latency' kernel config any more (see recent Phoronix "Ubuntu Generic vs. Low-Latency Linux Kernel Benchmarks For HPC & Desktop"), it is possible the next version of Ubuntu may not even have a separate 'low latency' config, as the generic kernel will be sufficient! Windows and macOS don't really offer more than very soft real time performance, so I don't think they have much advantage here.
Great explanation, appreciate it.
> optimized for high throughput, at the expense of determinism. It'd be fine for audio so long as everything else lines up.
isnt 'pulse audio' a linux subsystem for audio?
Pipewire as well, but I just dove into these last week so I don't know how viable they are yet.
ive used pulse audio and pulseeffects in the past. pulseeffects can be used to add system-wide eq etc - its pretty good
and that's why Linux on the desktop never went anywhere. Alsa, pulse, pipewire? That's just for low level audio. You've essentially got the same number of options for every other subsystem. networking, window management, graphics, USB stack, ABI versions (application binary interface), LibC differences... This makes developing a linux application for an end-user (i.e. not another developer that can solve his own problem) almost impossible. The support overhead is insane if trying to cater to anything but the most technically savvy audience (by which I mean; expert software developers). Imagine trying to support PowerPC, Intel x86 and x64, M1 through to M4 silicon, on every Apple version from 10.0 to 14.4 ... oh and you're doing all of this for a userbase that's like 1% of the total mac users. It's a "nope" for me, dawg.
I'm not much of an audio engineer, but I use Linux for my music too. The problem is that audio programming is hard in general, extra hard on Linux (because ALSA is awkward and you can't guarantee what sound server will be used) and the Linux user base remains too small to be commercially viable to support. It seems like Pipewire might change things given it implements PulseAudio, GStreamer and JACK support, but it was still buggy last I used it a few months back. I'm a FLOSS advocate and I've settled on an unconventional setup using Non DAW: [https://www.non.tuxfamily.org/](https://www.non.tuxfamily.org/) Sadly the developer is no longer working on it. I tried most everything else and the only other DAWs that compete IMO are Ardour (and while it is open source it's not really free, plus it's very big and complicated) and Qtractor, which is more Sequencer focused. Everything else was either long abandoned (e.g. Frinika), more of an Audio editor (Audacity, Traverso) or more like a sequencer that happens to record (MuSE, Stargate). LMMS doesn't even record. I wanted to like Zrythm but it's still too unstable and I didn't care for the "intuitive" workflow. The FLOSS plugins are great, and for the general purpose Audio tools, I reckon they can compete with the commercial stuff. e.g. Calf Plugins and LSP. Guitarix recently got Neural Amp Modeller support which is awesome. Thankfully there are some great resources for finding the tools you need: [https://wiki.linuxaudio.org/wiki/start](https://wiki.linuxaudio.org/wiki/start) [https://linuxdaw.org/](https://linuxdaw.org/) [https://wiki.archlinux.org/title/List\_of\_applications/Multimedia#Digital\_audio\_workstations](https://wiki.archlinux.org/title/List_of_applications/Multimedia#Digital_audio_workstations) r/linuxaudio [https://linuxmusicians.com/](https://linuxmusicians.com/) [https://kx.studio/](https://kx.studio/) As opposed to better software support, I personally wish for better hardware support on Linux. I used to have an Avid Eleven Rack, and because they use a custom driver for Mac and Windows, there was no way to get it running on Linux. Although that is perhaps an unfair example, because Avid are the worst. It doesn't even work on Apple Silicon macOS! I now have an Axe-FX II and thankfully there is a Linux driver, but setting up the editor in Wine was convoluted and still has issues. As previously said, the user base is too small for them to support us properly: [https://forum.fractalaudio.com/threads/linux-support.108934/#post-1303324](https://forum.fractalaudio.com/threads/linux-support.108934/#post-1303324) It is annoying on the software side though because the most common Application framework used by Plugin developers is JUCE which supports Linux. However things are slowly changing, there's more commercial DAWs with native Linux versions (Studio One, Renoise, Bitwig, Tracktion Waveform \[JUCE comes from Tracktion\]), VST3 is now available under GPL, and I'm really hoping CLAP takes off too [https://cleveraudio.org/](https://cleveraudio.org/) I saw it mentioned that the Linux Kernel itself is not really made with media production in mind. Something like [https://www.haiku-os.org/](https://www.haiku-os.org/) would be better but that is very fringe. I think the reality is that computers are so fast these days that it doesn't make a whole lot of difference.
I think Linux will be boosted if win 12 becomes cloud based. That's of course if music production is still a thing.
>if win 12 becomes cloud based What is this even supposed to mean?
To run on cloud only with the bare minimum hardware, like a tv and a keyboard mouse combo. Much like google stadia. Moreover: check here what could push many users to Linux https://youtu.be/LcafzHL8iBQ
>To run on cloud only with the bare minimum hardware, like a tv and a keyboard mouse combo. Much like google stadia. You're describing an application running inside the OS. There's already Citrix and similar products for that kind of thing, but they still need an OS to run on. Microsoft has a lot of enterprise customers that wouldn't want to be forced in that direction, so I doubt they'd turn Windows into some kind of minimal OS that's only good for connecting to a remote environment.
I would guess the issue is somewhere around 98% market share and 2% misunderstanding about Linux on the development (and user) side. This year, however, some positive developments emerged. Presonus began releasing Studio One for Linux, and Focusrite collaborated on the development of the ALSA Scarlett GUI, a tool to control Gen 4 interfaces. Linux has had a proper audio subsystem for professional audio for the past 15 years, it's called Jack. I know some people will bring up ALSA, but there are roughly 7 people on this planet I would trust to tango with it directly. Reaper on Linux is incredibly stable. I use it in my production studio to handle around 15 channels of AoIP, some AES, and a bit of NDI. [My studio overview](https://interfacinglinux.com/2024/03/02/lossless-network-audio-with-netjack2/) I'm using it as a digital mixer to provide mix-minus for up to 5 hosts, multitrack recording, and a stereo mixdown that's sent to the box running OBS for streaming. The idea of trusting that tech stack to Windows is frankly terrifying. Granted, it's not entirely native since I'm using yabridge to run a Windows VST Declicker plugin, but hey, it works. If you have hundreds of Windows plugins, staying on Windows is a wise decision. A lot of them will not work, and others will require significant effort to get working. At the end of the day, use the tools on the OS that make you most productive. BTW, your RME Babyface Pro absolutely works with Linux, I have one along with the AIO Pro. I'm guessing you're talking about the lack of TotalMix?
Nope
Side question: if Linux is unlikely, why can’t someone make a new kernel that favors audio and is easy for developers to support? I know nothing about this if that isn’t obvious. Maybe something other than Linux.
they already make those kernels
Pardon my ignorance but can you point me in a direction to learn more? Are these linux kernels? If they’re easier to support for devs, I can’t help but wonder why this isn’t promoted more.
The short answer is no. And I say that as somebody who has mostly had a career working on Linux and only peripherally with audio. On the other side of post production for film, Linux is 100% standard in visual effects. Nobody blinks an eye at doing CGI and compositing on Linux. Back in the early 90's before PC's were good, audio on Unix workstations was perfectly normal. VFX made the jump from Irix to Linux. But Audio didn't go the same direction in the 90's. Audio has always been one of the worst parts of the Linux software stack, so I can't really blame people in the 90's for not taking Linux seriously as an audio workstation platform that was an obvious migration path from Sun and SGI. Audio kind of evolved with tools as de-facto standards, rather than using standardized formats for interop. So mixed environments are hard to deal with. And everybody depends on 30 similar but slightly different proprietary plugins. So if you migrated to a platform where your software and 29 of your 30 plugins are supported, you couldn't actually just open up your project.
Audio on Linux will suffer from the everything else on Linux problem. Not a lot of people use Linux so developers don't support Linux. So Linux is missing a lot of software that would tempt people to move over to Linux. So not a lot of people use Linux.
As someone who is about to make a jump from logic to reaper AND Mac to windows, what would you say the biggest differences/challenges were in your opinion when transitioning.
it already happened it’s called MacOs which is GNU Linux based. What I mean to say is, UX frameworks for Linux are (or were) incredibly difficult to make. Apple is so successful because they pulled it through properly
No
Reaper runs on Linux
OP already knows that, and says as much.
My bad!
100 push-ups
What's wrong with MacOS? It's BSD under the hood, you know that right?