Future of Windows in pro audio

[ampetrosillo]

By the way, the idea that 1-2% of audio software is enough because 1-2% of people use Linux wasn't as simplistic as the refutal makes it to be. My argument is that this is already an overperformance. And also a perfectly workable overperformance. You can produce a whole electronic album with Bitwig Studio alone without using third party plugins.

[Tiles]

But the thing is.

We say "Reaper is a good DAW", or "Bitwig is a good DAW" (I won't even mention Ardour despite being, again, a good DAW) but to you, it is not good enough. For Linux to be even in the conversation when talking about audio production, only the combination of Ableton, Cubase and ProTools matters to you. But I'm not convinced. Linux manages to achieve something like 3-4% of the user share, apparently. Let's even halve that, or more. 1-2%. It follows that it should aspire to, say, 1-2% at most of the musician population. (I say at most because most Linux users are technical). Having five DAWs (Ardour, Bitwig, Reaper, Studio Pro, Tracktion, of which at least Bitwig can be considered to have the polish you expect from a commercial offering on any platform anywhere) on such a small platform, to me, is already an impressive achievement. And things can only grow. You gotta start somewhere.

Again you put words into my mouth.

The issue isn’t whether Reaper, Bitwig, or Ardour are ‘good’. That’s not the bar being discussed.

The point is about industry relevance and ecosystem compatibility. In professional audio, tools like Ableton Live, Cubase, and Pro Tools aren’t just arbitrary preferences, they’re de facto standards because of project exchange, studio workflows, and third party integrations.

Saying ‘Linux has good DAWs’ doesn’t address that gap. It’s answering a different question.

And the market share argument cuts both ways. Yes, 1–2% is small, but that’s exactly why major vendors don’t prioritize Linux support. It’s not about dismissing Linux, it’s about the economic reality of maintaining complex, plugin heavy audio software across a fragmented platform.

So no, it’s not about ‘not good enough’. It’s about whether the platform can realistically participate in the same workflows and ecosystems. Right now, that’s still the limiting factor.

[Tiles]

But the thing is.

We say "Reaper is a good DAW", or "Bitwig is a good DAW" (I won't even mention Ardour despite being, again, a good DAW) but to you, it is not good enough. For Linux to be even in the conversation when talking about audio production, only the combination of Ableton, Cubase and ProTools matters to you. But I'm not convinced. Linux manages to achieve something like 3-4% of the user share, apparently. Let's even halve that, or more. 1-2%. It follows that it should aspire to, say, 1-2% at most of the musician population. (I say at most because most Linux users are technical). Having five DAWs (Ardour, Bitwig, Reaper, Studio Pro, Tracktion, of which at least Bitwig can be considered to have the polish you expect from a commercial offering on any platform anywhere) on such a small platform, to me, is already an impressive achievement. And things can only grow. You gotta start somewhere.

For fun, I did what Tiles would do. I copy/pasted your comment into an AI and asked it to refute your message in a condescending tone. What's funny, is that Tiles doesn't even need to be around to make him speak. He's like a sock puppet!

Here's AI's refutation just for fun:

Let’s slow this down a bit, because you’re stacking a lot of assumptions and hoping nobody notices.
First, nobody said Reaper, Bitwig, or Ardour “aren’t good enough.” What’s being challenged is the leap from “these DAWs exist and work” to “Linux is meaningfully competitive for professional audio.” Those are not the same claim, no matter how much you’d like them to be.
Second, the market‑share argument simply doesn’t do the work you think it does.
“Linux has 1–2% of musicians, therefore it should only need 1–2%‑quality tooling” is not how ecosystems work. Professionals don’t pick platforms by proportional representation; they pick the platforms that remove friction, integrate with the rest of the industry, and are supported by vendors, studios, collaborators, hardware manufacturers, and clients. Ableton, Cubase, and Pro Tools matter not because they’re fashionable, but because they are the lingua franca of commercial music production. Denying that is not radical—it’s naïve.
Third, listing the number of Linux DAWs as an achievement is… generous. Five DAWs on a platform doesn’t tell us anything about:

third‑party plugin availability,
industry-standard session interchange,
hardware driver support,
post‑production workflows,
or outside‑the‑bubble collaboration.

Quantity of DAWs is irrelevant if each one lives in a partial ecosystem. Fragmentation isn’t strength; it’s overhead. Professionals optimize for reduced cognitive load and predictable outcomes, not ideological diversity.
Fourth, calling Bitwig “polished enough to meet expectations on any platform anywhere” quietly undermines the rest of your argument. Bitwig succeeds precisely because it doesn’t behave like a typical Linux project: it’s commercially driven, tightly scoped, and largely insulated from Linux’s usual audio stack chaos. If Bitwig is your flagship example, you’re conceding the point—not refuting it.
Finally, “you gotta start somewhere” is not an argument; it’s a consolation prize. Linux has been “starting somewhere” in pro audio for over two decades. At some point, continued appeals to potential stop sounding optimistic and start sounding evasive.
So yes—Linux audio tools are impressive given their constraints.
No—that doesn’t make Linux a peer competitor to platforms anchored by Ableton, Cubase, and Pro Tools.
And pretending those two statements are equivalent is wishful thinking dressed up as realism.
If the goal is enthusiasm, say enthusiasm.
If the goal is professional parity, then the bar is higher—whether that’s comfortable to admit or not.

Thanks for demonstrating my point, I guess. You went out of your way to generate a counterargument instead of writing one yourself, and somehow that’s supposed to discredit me.

If we’re done with the meta commentary, the actual argument you posted just repeats what I’ve been saying the whole time.

In professional audio, tools like Ableton Live, Cubase, and Pro Tools dominate because of ecosystem, compatibility, and industry workflows. That’s not a value judgment, it’s an observation about how the industry operates.

Pointing out that Linux has capable DAWs doesn’t address that gap. It answers a different question.

If you disagree with that, feel free to explain where Linux currently matches that level of integration across plugins, hardware, collaboration, and studio exchange. Otherwise, this AI detour isn’t really adding anything to the discussion. But yet again proofs what you really are.

[Tiles]

By the way, the idea that 1-2% of audio software is enough because 1-2% of people use Linux wasn't as simplistic as the refutal makes it to be. My argument is that this is already an overperformance. And also a perfectly workable overperformance. You can produce a whole electronic album with Bitwig Studio alone without using third party plugins.

Shifting the goalpost again ...

Nobody is arguing that you can’t produce an album on Linux. Of course you can. You can also produce a full track in Bitwig Studio alone without third party plugins. You can even play Doom on a frigerator, and declare it to the ultimative gaming station. That’s not in question.

What’s being discussed is whether that translates into parity with established professional workflows.

Being able to work in isolation isn’t the same as being able to integrate. In real world scenarios, people exchange projects, rely on specific plugins, collaborate across studios, and depend on hardware and vendor support that’s built around tools like Ableton Live, Cubase, and Pro Tools.

So yes, it’s an overperformance in the sense that Linux offers capable tools despite its size. But calling it “perfectly workable” depends entirely on the context. For solo, self contained hobby production with low goals, sure. For broader industry integration, that’s exactly where the limitations still show.

That distinction is the whole point.

[Tiles]

This last comment was, in fact, very AI-ish. Handwavey as AI is wont to do.

Agreed. I've started not responding back to him at all. I definitely don't care about what he has to say. I only wish KVR had a way to not show quoted text from the users we've muted if we've muted them. (Not counting what you posted, @Lunardigs, because what you posted proves a good point.) Then I wouldn't have to see any of the comments at all.

He's terrible ...
Why would anyone want to talk/argue with a guy responding with massive blocks of AI generated text?

Yeah, it’s wild. Next thing you know people will start judging arguments by their content instead of their word count.

Also interesting criticism about ‘long replies’ coming from the group of people who just quote-stacked half the thread. And cannot stop bitching about not agreeing to their disproven arguments.

But sure, let’s blame ChatGPT.

If you pull me into a discussion, expect an answer. The quality of it depends on the quality of what you bring.

[ampetrosillo]

By the way, the idea that 1-2% of audio software is enough because 1-2% of people use Linux wasn't as simplistic as the refutal makes it to be. My argument is that this is already an overperformance. And also a perfectly workable overperformance. You can produce a whole electronic album with Bitwig Studio alone without using third party plugins.

Shifting the goalpost again ...

Nobody is arguing that you can’t produce an album on Linux. Of course you can. You can also produce a full track in Bitwig Studio alone without third party plugins. You can even play Doom on a frigerator, and declare it to the ultimative gaming station. That’s not in question.

What’s being discussed is whether that translates into parity with established professional workflows.

Being able to work in isolation isn’t the same as being able to integrate. In real world scenarios, people exchange projects, rely on specific plugins, collaborate across studios, and depend on hardware and vendor support that’s built around tools like Ableton Live, Cubase, and Pro Tools.

So yes, it’s an overperformance in the sense that Linux offers capable tools despite its size. But calling it “perfectly workable” depends entirely on the context. For solo, self contained hobby production with low goals, sure. For broader industry integration, that’s exactly where the limitations still show.

That distinction is the whole point.

What are these "professional workflows"? Do you really think it matters as much in 2026 as in 1996, when vendor lock-in was unfortunate but very real? With basically as many as at least four commonly used DAWs (Logic, which you can only run on a Mac, Cubase, ProTools, Ableton) and a lot of relatively minor but significant players, professional workflows largely revolve around stems. Collaborations may choose to work with one DAW only, but it's not that important. At the end of the day, it is one, two, three+ doing the tracking (depending on how distributed is the tracking process), one doing the arrangement, one doing the mixing, one doing the mastering etc. and they all (can) work using simple .wav files. Professional workflows using DAW projects have other constraints anyway, such as plugins (do you expect all studios to have the same plugins?). So no, it's not like by using Reaper or Bitwig or even Ardour you can't collaborate with anybody. It's a claim that you or your AI of choice definitely need to back up. The original claim was that it is very annoying to code for Linux because of the fragmentation, but again, this can be made to work with a tiny little bit of overhead (compared to the rest of the development process, really). So the ecosystem is growing, the DAWs available are more than enough to support high-quality audio production, the Linux desktop is still problematic but there are strategies to deal with it. So I still maintain that you're being overly negative.

[Tiles]

You should buy more goalposts, they seem to move with every post. And don’t forget to bring fresh strawmen too.

Well, then, let's repeat the same arguments over and over, and hope that this time the reality changes to the better for you.

This tiny little bit of overhead is in reality massive.

There is a recurring pattern in this discussion of shifting the definition of “professional workflows” to make the comparison easier, but that doesn’t reflect how production environments actually work today.

Yes, exchange via stems is part of collaboration. Nobody is claiming otherwise. But that does not replace DAW ecosystems, plugin chains, session compatibility, and vendor-supported tooling in real production pipelines. Reducing everything to “it’s just WAV files anyway” ignores a large part of how modern projects are actually built, revised, and maintained.

DAW choice still matters. Workflows are not just isolated stages like tracking, arrangement, mixing, and mastering, they are iterative, collaborative sessions inside specific environments. That is exactly why tools like Ableton Live, Pro Tools, Cubase, or Logic Pro exist as industry standards rather than interchangeable components. And I also like to mention that years of expertise are at stake; you don't just give that up.

A key part that is still missing is the depth of the commercial plugin ecosystem. On Windows and macOS you have established industry standards like iZotope (for example Ozone, RX, Neutron), FabFilter, Waves Audio, or Universal Audio. These are deeply integrated into professional workflows across mixing and mastering.

On Linux, this layer is largely missing natively. A significant part of that ecosystem is either unavailable or only usable via compatibility layers like yabridge, which introduces overhead, fragility, and no vendor support when issues arise. That is not equivalent to native, first-class platform support.

This is not only a professional workflow issue.

In fact, hobbyists are often affected even more by the missing ecosystem. Professionals can sometimes work around limitations through hardware, budgets, dedicated setups, or locked-in studio environments. Hobbyists don’t have that flexibility.

They are far more dependent on out-of-the-box compatibility, broad plugin availability, and frictionless setup. When that ecosystem is missing or fragmented, it has a much larger impact on accessibility, learning curve, and creative flow.

So the disagreement is not whether Linux audio can be used for production. It clearly can. Like you can play Doom on a frigerator. The question is whether it is equivalent in ecosystem maturity, vendor support, and friction in real-world workflows. On those criteria, the gap is still substantial, even if it has narrowed compared to the past.

[Tiles]

double post trap ...

[ampetrosillo]

You keep saying those things, you keep throwing around "modern production workflows". Yes, I won't be able on Linux to open an Ableton project and tweak the filter or Operator to make it sound a little bit different. I won't be able to adjust automation items. You also don't want to. Each step of the process is done by ONE person. Too many cooks spoil the broth. So, this is largely moot.

Also, if I'm doing the mixing, really, I don't want nor need the musicians' projects. I want their files. I want to focus on what they have brought onto the table and not on what they could have brought onto the table, that's a recipe for disaster.

I am not shifting the goalposts. This is not playing Doom on a fridge, a very condescending way to characterise audio production on Linux. I am the first to acknowledge the difficulty, but I am also the first to acknowledge that things are getting better and better each week, and it's not the black hole you make it to be.

[Tiles]

So you are still searching for a framing that preserves your conclusion rather than addressing the original point.

The original point of the discussion was not about individual audio production preferences or stem-based workflows. It was about the development overhead caused by Linux fragmentation and ecosystem variability, and its downstream effects on ecosystem size and vendor adoption.

That includes things like inconsistent distributions, differing library versions, audio stack differences, packaging formats, and the need to support multiple integration paths (PipeWire, JACK, ALSA, different kernel configurations, etc.). From a developer perspective, that is where the cost and complexity come in, because it directly affects testing matrix size, support burden, and reproducibility.

A simple example of this is packaging and deployment. On Windows, a Python application can often be turned into a distributable executable using tools like PyInstaller with relatively low friction. On Linux, the same application typically requires additional considerations such as virtual environments, system library dependencies, and distribution-specific packaging decisions. This is not about capability, but about variability in how the target system is composed.

Your argument about “modern production workflows” and stems is addressing a different topic. Even if stem-based collaboration works perfectly, it has no bearing on the engineering problem of platform fragmentation and maintenance overhead.

These are two separate discussions:
one about how audio production is structured,
and one about the cost of developing and supporting software on Linux as a target platform.

The latter was the original point, and it remains independent of whether Linux audio workflows are usable or improving.

And one word about your claim that the overhead is "marginal".

Just to understand your perspective better: what is your experience with Linux as a primary development target across multiple distributions and long-term maintenance scenarios?

From a practical development perspective, calling the overhead “marginal” is exactly where the disagreement lies, and it also depends on what perspective you are taking.

For a single developer working on a small application in isolation, the overhead can feel manageable. But that is not how most real-world software is developed or maintained.

Once you look at distribution support, packaging differences, dependency fragmentation, audio stack combinations, kernel variations, and long-term maintenance across multiple environments, the cost is not just about initial setup, but about ongoing testing, debugging, and support complexity.

This is especially relevant in domains where timing, system configuration, and low-level behavior matter.

So the question is not whether Linux is usable or whether development is possible. It clearly is. The question is whether the additional complexity compared to a more uniform target environment is marginal or structurally significant over time and across a user base.

That is the actual point of disagreement.

[ampetrosillo]

And again, I have told you that the Linux ecosystem has realised the need to accomodate proprietary software (containers, which largely address the issue. Not totally, but 90%) and the differing audio stacks are no different than on Windows (where you have non-native ASIO, with each vendor spinning their own driver which is *worse*, WASAPI, etc.). The reason why developers do not target Linux is simple: they don't see the profit motivation. This is why SSL shut down Harrison on Linux, this is why many vendors don't even go down this route. The technical aspects are really only secondary.

[Tiles]

Ah, new goalposts. And new strawmen

You are mixing two separate factors here again: market incentives and technical overhead.

Yes, profit motivation absolutely plays a role in platform support decisions. Nobody is denying that. But that does not make the technical aspects “secondary” or irrelevant. In practice, both are linked.

If supporting a platform comes with higher development, testing, and maintenance overhead, the return on investment threshold is higher. Fragmentation, multiple packaging targets, varying system libraries, and different integration paths all contribute to that cost. That directly feeds into the business decision, it does not sit outside of it.

Containers can help with parts of distribution, but they do not eliminate the underlying variability. You still have to deal with audio stack integration, low-level system behavior, and user environment differences. Saying this is “90% solved” is not something that aligns with real-world support and maintenance experience.

From practical experience, even container-based setups can introduce significant setup and debugging overhead in certain cases, especially when system-level components like audio stacks or hardware access are involved. I’ve personally spent weeks on Docker-based environments that were far from trivial to stabilise compared to straightforward installation and deployment models on other platforms.

The comparison to Windows audio stacks also misses an important distinction. While Windows has multiple APIs like WASAPI and vendor-specific ASIO drivers, it is still a single, controlled platform with a consistent baseline for deployment and support. Linux, by design, spans multiple distributions, library versions, packaging systems, and configurations. That is a different class of variability.

So again, the point is not whether Linux can run audio software or whether workarounds exist. It is about the cumulative overhead of supporting it as a primary platform. That overhead is part of the reason why the ecosystem and vendor support look the way they do, alongside market considerations.

This is also reflected in the market itself: vendor support follows economic viability, and platform fragmentation increases the cost of entering and maintaining that support.

Just to understand your perspective better: what is your experience with Linux as a primary development target across multiple distributions and long-term maintenance scenarios?

Since you didn’t answer the question about your experience, I’ll take that as an indication that your assessment isn’t based on sustained work with Linux as a primary development target across multiple distributions and long-term maintenance contexts. Or to tell the brutal truth, and completely without ChatGPT: you have no idea what you are talking about. And try to explain a developer how to develop.

That matters, because the discussion here is specifically about development overhead in real-world multi-environment scenarios, not isolated or theoretical cases.

In that context, the distinction between “manageable” and “marginal” depends heavily on practical exposure to exactly those conditions.

Repeatedly pointing to REAPER and similar exceptions is a classic case of drawing a general conclusion from a limited set of examples, taken out of context. It is not proof that the overhead is marginal, something that you are not able to judge anyways, and it does not address the actual point. It only shows that supporting Linux is possible, not that the cost and complexity are negligible or comparable across different products and companies.

That distinction has been the core issue all along: development overhead, long-term maintenance, and platform variability. Repeating the same counterexample does not change that.

We’ve been going in circles for quite a while now, including repeated shifts in the scope of the argument. I was so kind to follow it.

At this point, we are not adding new arguments, just restating positions.

[ampetrosillo]

Ah, new goalposts. And new strawmen

You are mixing two separate factors here again: market incentives and technical overhead.

Yes, profit motivation absolutely plays a role in platform support decisions. Nobody is denying that. But that does not make the technical aspects “secondary” or irrelevant. In practice, both are linked.

If supporting a platform comes with higher development, testing, and maintenance overhead, the return on investment threshold is higher. Fragmentation, multiple packaging targets, varying system libraries, and different integration paths all contribute to that cost. That directly feeds into the business decision, it does not sit outside of it.

Containers can help with parts of distribution, but they do not eliminate the underlying variability. You still have to deal with audio stack integration, low-level system behavior, and user environment differences. Saying this is “90% solved” is not something that aligns with real-world support and maintenance experience.

From practical experience, even container-based setups can introduce significant setup and debugging overhead in certain cases, especially when system-level components like audio stacks or hardware access are involved. I’ve personally spent weeks on Docker-based environments that were far from trivial to stabilise compared to straightforward installation and deployment models on other platforms.

The comparison to Windows audio stacks also misses an important distinction. While Windows has multiple APIs like WASAPI and vendor-specific ASIO drivers, it is still a single, controlled platform with a consistent baseline for deployment and support. Linux, by design, spans multiple distributions, library versions, packaging systems, and configurations. That is a different class of variability.

So again, the point is not whether Linux can run audio software or whether workarounds exist. It is about the cumulative overhead of supporting it as a primary platform. That overhead is part of the reason why the ecosystem and vendor support look the way they do, alongside market considerations.

This is also reflected in the market itself: vendor support follows economic viability, and platform fragmentation increases the cost of entering and maintaining that support.

Just to understand your perspective better: what is your experience with Linux as a primary development target across multiple distributions and long-term maintenance scenarios?

Since you didn’t answer the question about your experience, I’ll take that as an indication that your assessment isn’t based on sustained work with Linux as a primary development target across multiple distributions and long-term maintenance contexts. Or to tell the brutal truth, and completely without ChatGPT: you have no idea what you are talking about. And try to explain a developer how to develop. Not really clever.

That matters, because the discussion here is specifically about development overhead in real-world multi-environment scenarios, not isolated or theoretical cases.

In that context, the distinction between “manageable” and “marginal” depends heavily on practical exposure to exactly those conditions.

We’ve been going in circles for quite a while now, including repeated shifts in the scope of the argument. I was so kind to follow it.

Repeatedly pointing to REAPER and similar exceptions is a classic case of drawing a general conclusion from a limited set of examples, taken out of context. It is not proof that the overhead is marginal, something that you are not able to judge anyways, and it does not address the actual point. It only shows that supporting Linux is possible, not that the cost and complexity are negligible or comparable across different products and companies.

That distinction has been the core issue all along: development overhead, long-term maintenance, and platform variability. Repeating the same counterexample does not change that.

At this point, we are not adding new arguments, just restating positions.

I have worked as a project manager. I'm not a developer, but I know what the process entails. Before you even get to the technical aspects, many projects/goals are scrubbed away on the basis of sale projections. This is the real truth. All those technical aspects are stuff the engineers and developers may complain about, but they really are a secondary consideration.

Yes, multiplatform development is always increased overhead. It's a reason why games are basically never released for macOS, even with all the infrastructure in place making it easier. It's a reason why a lot of software is Mac only or Windows only. Never mind Linux. Apple is even worse because they pull the rug from beneath you from time to time. But guess what? There is far more software developed for both macOS and Windows than software which includes Linux, even when porting to macOS involves a significant rewrite, and that is simply because the macOS market is both bigger and more lucrative than Linux (but, guess what, Mac users do not play games much).

At the end of the day, all this stuff about Linux being fragmented, anarchic, unpredictable etc. is just busytalk by developers. And not even all developers, because, whether you agree or not, there is a lot more goodwill towards Linux among developers than you make it out to be (that may be dwindling due to cultural shifts and everything, but a lot of devs tend to be tolerant of the complexity of the Linux platform).

[Largos]

This is why SSL shut down Harrison on Linux....

SSL haven't shut down Harrison on Linux. Mixbus is still available for Linux.

[Tiles]

I'm not a developer,

I know. But i am

And now you shift everything from technical overview to business decides all.

Project management experience is relevant for understanding prioritisation, but it does not invalidate the technical cost side of platform support. These are different layers of the same decision process.

Yes, market viability determines whether a platform is supported at all. But the reason why supporting a platform is more or less expensive is still a technical question. Engineering overhead directly influences the business calculation. They are not separate domains where one makes the other irrelevant.

Multi-platform support being less common for macOS or Linux does not contradict this either. It is precisely an example of how increased porting and maintenance cost reduces platform coverage. The fact that companies make these trade-offs for economic reasons does not remove the underlying engineering complexity that drives those decisions.

Calling fragmentation and variability “busytalk by developers” also ignores that these are concrete, observable maintenance factors: dependency management, ABI/API differences, packaging systems, kernel/user-space interfaces, and audio stack integration differences. These are not abstract complaints, they are part of day-to-day support and QA work when a platform is actively targeted.

So again, market decisions and technical overhead are not competing explanations. The market reflects the cost structure, it does not replace it.