+1

Linux drivers would be a real reason to fully make the switch to Linux!

Free the DSP!

Linux is the future!

Since 20 years this is poping up all the time.

When will this future start ? in 200 years ?

My future is my Mac.
And the world-future will be an implant waver disk into brain that connects cameras and microphones replacing eyes and ears and also has a USB-C connector somewhere on the side of the head for internet.

Linux has not established any standard for multimedia production for private persons homecomputer, and will not.
There is no company behind, no power, no business, no future.

What is Linux ? What is the definition of?

you want a audio driver for Linux, ok.
Which one Linux ?
Debian ?
Manjaro ?
Ubuntu ?

If one provides a driver for Ubuntu,
next day some people comes : We are Linux-Manjaro community. We are strong community. We are growing community. We are the future. We need driver.

https://github.com/MrBollie/bbfpromix

https://www.reddit.com/r/linuxaudio/com … yface_pro/

Wouldn't the input metering in a web-Totalmix be slowed down or with huge latency ?

This raises some important questions about where things are heading.

Worth a look — what’s your take?

https://www.youtube.com/watch?v=_fw4HsJpfa8

The claim that if Windows market share declines “everyone will just move to Mac” feels a bit oversimplified, especially when you look at how today’s audio market actually works. The biggest customers for audio hardware, plugins, and DAWs are no longer large commercial studios — they’re home producers, hobbyists, streamers, podcasters, and independent musicians. That segment drives volume, and volume drives business decisions.

If a large portion of everyday users were to move away from Windows and toward something like Linux, it’s not obvious that they would automatically replace their existing machines with Apple hardware. macOS only runs on Apple devices, which means committing to a new, typically premium-priced computer. For many hobbyists, that’s a significant investment — money that could otherwise go toward microphones, interfaces, monitors, instruments, or software. Linux, by contrast, runs on a wide range of existing PC hardware and doesn’t require paying for the operating system itself. From a purely economic perspective, that’s a compelling alternative.

It’s often argued that “Mac is the industry standard” in pro audio. That has certainly been true in many professional studio environments. But the home recording market operates differently. Independent creators aren’t tied to long-standing studio infrastructure or legacy workflows in the same way. They tend to adopt tools that are accessible, affordable, and practical. If a meaningful share of new users were on Linux, developers of DAWs and plugins would have a clear financial incentive to support that platform. Software companies follow paying customers. Market share influences compatibility decisions far more than tradition does.

From a technical standpoint, Linux is not inherently unsuitable for audio production. Low-latency audio stacks and real-time kernel configurations already exist. The current limitations are largely about commercial support, driver availability, and ecosystem maturity — not fundamental capability. If user demand grew, manufacturers and developers would have reason to invest in native support, just as they have for other platforms when the market justified it.

The idea that everyone would default to Mac assumes that most users are willing to enter a single-vendor ecosystem and absorb higher hardware costs simply because Windows lost ground. In reality, many users prioritize flexibility, cost efficiency, and the ability to keep using their existing systems. An open, hardware-agnostic platform can be an attractive option under those conditions.

Mac would almost certainly gain some users if Windows declined; that’s reasonable. But the notion of a universal migration to Apple overlooks economic factors, the scale of the hobbyist market, and how software vendors actually make decisions. If a major shift occurred, it’s entirely plausible that the biggest beneficiary wouldn’t automatically be Apple — it could just as easily be Linux.

AFAIK, it's against the forum rules to post links to commercial and ad-driven content here, not to mention without providing an annotation or a summary, and even more so to do this for lobbying purposes. Reported.

To staff: the OP posted only one message and have never showed up since. At the same time, the thread attracted numerous trolls with similar activity record. I suggest closing the thread and also issuing warnings or even banning the ones who use this forum as a platform for political activism and commercial (and likely false) content promotion.

Op. It is not a technical problem to port drivers and TM Fx to linux. The problem is in consistency of linux distros.
Win or MacOs, there's only one official edition, but different versions, say at least 5-8 previous version which RME still supports.
In case of linux, there's like a thousand distros, all based on a few main like debian, fedora, bsd, arch. Then there's many desktop envoronments like gnome, xfce, kde plasma, mate, enlightenment, cinnamon, pantheon, etc.
So that's literally a 100 different operating systems, not just two (win, macos).

It is same story Ableton did. They did port Ableton Live to a linux distribution, but it is only one version os and it is embeded into Push 3 standalone. They are not planing to share this particular Live linux port, bc it would get inconsistent, and they are a very respected and serious company and cannot afford to make their software inconsistent.

So having said that, if you're a serious musician, you will get yourself either a mac or win computer and get on with your work instead of spending your productive time tweaking a linux distro.

To follow up on Skrzak's post
https://forum.rme-audio.de/viewtopic.ph … 80#p249080

Additionally, you have to multiply that with different

Kernels
- Standard-Kernel
- Low-Latency-Kernel (CONFIG_PREEMPT)
- Real-Time-Kernel (PREEMPT_RT)
They may have different kernel parameters.

Scheduling and process priorization
- can be configured differently

Audio stacks
- ALSA (Advanced Linux Sound Architecture)
  Kernel-driver, library; access to hardware, basement for all higher layers
- JACK (Jack Audio Connection Kit)
  low latency server, standard for pro audio
- PulseAudio
   Desktop-Soundserver, focusses on consumer use, not for real-time, higher latency compared to Jack
- PipeWire
   Unified Server for Audio + Video.
   Replaces PulseAudio, integrates Jack

Studio-Setups
- ALSA direct
- ALSA + JACK
- ALSA + PipeWire (with JACK-API-Layer)

CPU and energy management settings

When the information is correct then you can achieve under best conditions already stability and low buffer sizes
with a low latency kernel as in Ubuntu Studio.

More stability you get with a real-time kernel like in AV-Linux and additional parametrization.

You can not force the world to use those two distributions.

So the issue is

a) diversity between too many distributions
b) lack of commercial applications

It makes not sense to "simply get it to run".
The majority of applications that I use additionally have no Linux support.

I am not changing the OS for the sake of having Linux.
Linux should not become an end in itself (distribution diversity) but rather a standardized platform
that serves as the basis for as many software providers as possible

I have Windows for three reasons:
1- standardized platform as a good basement for everything
2- rich pool of applications (there you find all the de facto / standard applications of all areas)
3- modular/upgradeable hw platform at a fair price

Linux fails on #1 and #2 completely.

Nervertheless, if there would be Linux support, I would be glad to have a plan b just in case windows sucks more and more in terms of integration of KI services.

But everything needs to be doable and supportable and RME will surely know if Linux support is in scope or not or when.
For the time being the only solution / workaround to use RME hardware is by using CC-mode, but then no TM FX application.

Hi Ramses,

I want to comment on a few points from your post:

First of all, you make many good and valid points. If the world were ideal, these challenges – distribution diversity, lack of commercial applications, and differences in kernels and audio stacks – could be addressed together by developers and the community. This could lead to a sort of consensus and a shared direction that benefits both users and manufacturers.

Distribution diversity and standardization
It’s true that there are many Linux distributions, but in practice, many plugin and audio software vendors now consider Ubuntu LTS the de facto standard. This means that most commercial audio plugins work directly on Ubuntu LTS, so the wide variety of distributions is not as big an issue as it might seem.

Kernels and latency
A low-latency kernel (like in Ubuntu Studio) is often sufficient for small buffer sizes and stable operation. A real-time kernel is mainly needed for very heavy, professional sessions, but most plugin-based work does not require it.

Audio stacks

ALSA + JACK is still the standard for pro audio, and PipeWire has evolved to integrate well with the JACK API layer.

PulseAudio is not ideal for real-time audio, but its desktop support is useful for general purposes.

Linux vs. Windows
It’s true that Windows offers a wide application pool and a modular hardware platform. However, if RME expanded Linux support (e.g., TM FX in addition to CC mode), Ubuntu LTS could already run many pro audio applications in a stable and standardized way today.

Tuning and stability
Ubuntu Studio comes with a low-latency kernel by default, and with proper CPU and power management settings, it already provides a very stable system. Linux use does not require radical distribution changes.

In summary: while Linux may not yet be “ready” for all commercial applications, Ubuntu LTS already provides a stable, standardized base for most plugins and pro audio software. This significantly reduces diversity and compatibility concerns and could be a realistic option for those who want Linux support without compromising stability.

I personally use Ubuntu Studio and an RME UFX. It works well enough for me: I can do all my studio work, and my clients have never complained. However, that doesn’t mean it’s suitable for everyone. That’s why it’s good to have options.

On important to clarify one technical point:

Linux in this context primarily means the kernel. Drivers are written for the Linux kernel — not for individual distributions. If a driver is properly implemented and either merged upstream or built against the standard in-kernel APIs, it will generally work on all distributions running a compatible kernel version and architecture.

In other words, the driver layer is already largely standardized. Distributions differ in packaging, defaults, and release cycles, but they all share the same kernel foundation.

Of course, the kernel does not guarantee a completely stable internal ABI across major versions. Out-of-tree drivers sometimes need adjustments when kernel versions change. However, this is not a distribution problem — it is a kernel version compatibility matter. If a driver is maintained properly (or upstreamed), it works across distributions.

The same separation applies to user-space applications like TotalMix FX. That is not a kernel component but a user-space program communicating with the driver. Such software can be delivered in multiple standardized ways:

DEB packages (Debian/Ubuntu family)

RPM packages (Red Hat/Fedora family)

Or distribution-independent formats like Flatpak, Snap, or AppImage

Modern Linux already provides mechanisms for “build once, run on most systems” at the user-space level.

So technically speaking, the ecosystem is far more standardized than it might appear from the outside. The real complexity is usually not kernel diversity itself, but support boundaries and resource allocation.

From a purely architectural perspective, supporting a clearly defined kernel baseline (for example a specific LTS kernel series) and one packaging target is entirely feasible within the current Linux ecosystem.

Looking at this calmly and over the long term, it is entirely realistic that more and more plugins and major audio software will gain Linux support. The technical barrier is no longer the limiting factor — many modern audio applications are already built on cross-platform frameworks, and targeting Linux is not an architectural outlier. The main considerations are often validation, packaging, and support organization rather than rewriting the software.

Development is also not driven by forum debates or opinions, but by market dynamics. If:

the user base grows steadily,

hardware support improves,

a few major players set an example,

others will naturally follow. This pattern has repeated itself many times in technology.

It’s important to remember that platform adoption can change gradually and almost imperceptibly. First, Linux may be “unsupported.” Then “experimental.” Then “partially supported.” Finally, “officially supported.” This happens incrementally, not all at once.

Once plugin support begins to stabilize, it is no longer an ideological discussion but a rational risk-and-cost calculation. When porting and support costs are manageable and enough paying users exist, the decision becomes logical.

Therefore, it is reasonable to assume that the transitional issues we see today — such as limited plugin availability — are temporary. They may not disappear overnight, but they are not permanent barriers.

Linux may not become an instant megatrend on the desktop. But it is entirely plausible that it will gradually become a normal, accepted third platform in the pro audio world. And once a critical mass is reached, the growth feeds on itself — regardless of what individual forum debates predict.

If we look at stereotypes, the reality is that they exist in all operating system communities, not just Linux. Ironically, this discussion itself actually shows more suspicion and negative assumptions about Linux users than factual issues.

In practice, choosing Linux is about control, freedom, and technical optimization – not envy, compulsion, or ideology. The same goes for Mac and Windows users: their choices are based on needs and habits, not hostility toward others.

Discussions work best when everyone sticks to fact-based observations and technical perspectives, rather than letting stereotypes drive assumptions or accuse communities based on emotion.

I wonder why Mac and Windows users are so active in the Linux section of the RME forum? The discussion could stay focused on technical facts and experiences, but it often turns into ideology or confrontation. It would be more productive to stick to facts and share practical experiences with Linux and RME devices.

@Mike Shield
Do not forget, that "little" change in Linux core may also require to update firmware of RME interfaces, not "only" drivers. So, a lot of work and testing....

Have you noticed how much effort RME had to invest to adapt to Apple Silicon? And it still seems not working for some of users...

And Linux may run on various CPUs. Do you expect RME to support x86 or ARM or .....? And no, RME will not provide sourcecode for drivers, so that it may be compiled by users for CPU they wish.

The driver alone doesn't make it. There are several components that need to work well / "hand in hand".
Kernel version, USB driver/transport, special settings (energy, process prio), background services, etc.

Then you have the programming and GUI part for TotalMix FX and other RME applications.
As a vendor, you also need to ensure that installers work well for every distribution.

Because of the diversity of Linux there might be different methodologies where special settings need to be done.
Also disturbing can be the very different shell environments.

It might also be challenging that you have two different versions of X-Windows implementation.
Then every Linux is mixed out of different kernel, development system, library versions, tools of different versions,
This opens a can of worms that can create different types of failures.

Flatpaks can mitigate it only up to a certain point, comparable to runtime libraries that you have to install additionally on a Windows system. But it doesn't solve everything because some issues can be in the kernel/the driver or due to a certain
customization where every distribution will be different.

As every vendor has to administer the customer's system to a certain extent, you need to have knowledge about all the different possibilities that can occur on different distributions. Many customers are not an "expert" in terms of Windows OS, guess how this will be on a Unix system.

Nice idea, but as I know Unix very well and if I see how customized all these different distributions are I think this is all not as easy as you think.

But under Windows, it is still one Windows release from one vendor.
With a ~ half-yearly release cycle: 21H2, 22H1, 22H2, ...
There are a couple of years until the next major release is out.
Windows includes stable drivers for hundreds of devices that do not change that often.
By far not that diversity that you have in Linux.

At this point, I’m not sure there’s much more to add.

This discussion probably won’t change your view, and it won’t change mine either. In the end, RME has the keys here — they can decide to support Linux or not. That’s entirely up to them.

We can debate the technical side all day, but the final call is theirs.

So I think we’ve both made our points.

I guess, it is the same/similar like fly to the Moon. It is technically possible, people even were there 50+ years ago. And the technology, mainly the computers and materials, has advanced significantly since then. Many countries have technical knowledge to do it. Just... So far, Americans were the first and the last.

Generally, if there is no benefit from doing something, there is not much pull to do it....

Russians could land on the Moon, but being the second probably was not atractive enought to put it in reality.

About 382 kg rocks where brought to earth from moon, after all that people come up with the earth is flat

Thanks for bringing this up and thanks for the discussion.

I have to admit it would be a good thing to have the choice to buy a laptop for less money without windows on it but Linux pre-installed.

Would also be interesting to find out how many of these computers would be used as Linux computers.
Lots will put Windows on it without license I guess.

summarize :

Youtube video from post 11 wants to share a huge sensation, Lenovo brings out Linux-laptops

Youtube video from post 38 reveals : it was fake-news

In my opinion it was ok to post both videos links for pushing the Linux discussion
many interesting inputs did follow, for example post 29

Apologies if I need to mention users’ nicknames in this post – I do so only for clarity, not personally.

Thanks to Waedi and Ramses for the constructive discussion – I appreciate that you have stayed on topic.

I do wonder, however, why Unplugged seems to constantly target me and portray me almost as a criminal. I have not broken any rules nor acted inappropriately. I participate here with the same rights as anyone else.

Regarding the promotion of Linux in audio work, especially with RME devices, I don’t see that my posts have caused anyone any harm. My intention has been to share experiences and information with those who are interested. Highlighting alternatives and technical perspectives is not an attack on anyone.

If there is something concrete to point out about my posts, I hope it is stated directly, with reasoning, and respectfully – not through hints or labeling. Disagreement is welcome, but personal attacks do not contribute to the discussion.

I can also provide a short summary of video content if that helps Unplugged’s peace of mind and clarifies what is being discussed.

If there is interest, I can also share more material in the future and practical examples of how studio work is done with RME devices and Linux. The aim is not to present the only correct way, but to show functional solutions for those genuinely interested.

Let’s keep the discussion on topic and constructive.

Yeah, absolutely...

I am not RME... but should I introduce a donate option in my repo (https://github.com/huddx01/oscmix)?

Thanks. Nice to hear. But, you don’t owe me anything. Personally, it’s just a passion to learn new things…

However, I don’t understand why RME should start a funding campaign towards this?

Seriously, If you know how to organize such funding things and have the passion and organizational skills - nice idea. So, why don’t starting such a campaign yourself, get some donators and devs… you’ll have at least one free-time-developer supporting your campaign…