What progress has Linux audio made in 2025?

[thcrock]

My take on the original question is that the fallout from JUCE8 in Wine actually got us a fair number of new commercial effect plugin developers releasing natively on Linux; Toneboosters, Kazrog, DDMF, Korneff, Ohlhorst Digital (technically OHD was early 2026 I guess). They may not be Waves or Fabfilter level market penetration but they aren't unknown or anything. I routinely see them getting reviewed on mixing channels, and they do increase options quite a bit for people doing mixing and mastering on Linux without having to bridge.

Instrument-wise, fewer changes or at least less that directly affect me. Audiomodern did release Soundbox (I forget if this was late 2025 or early 2026), which did increase the number of commercial sampled instruments available. Sforzando released a native version? The most promising thing to me was just the upcoming Koda sampler confirming Linux native is in their roadmap. The type of sampled instruments they are advertising is more up my alley. Technically that was 2026 too. We'll check back in next year to see if they actually released it in 2026!

Hardware/distro/kernel stuff I don't pay too much attention to so I have nothing to add there. My hardware and my distro work so I don't really pay attention to what changes from year to year.

[audiojunkie]

Yes, low latency. But that's not PREEMPT_RT.

Has anybody even given it a comparitive spin with audio?

Let me be more specific. I meant "Low Latency Audio", not Low Latency in general.

Every single person who is using Ubuntu Studio (and most probably most other Ubuntu derivatives) are using the Low Latency configured kernel.

Many people are getting sub 5 ms latencies (ROUND TRIP!!) Not everyone, of course, but many.

Of course. But that is nothing new that came with kernel 6.12.

A lack of specific testing also makes it impossible to figure whether the normal preemption models really have a problem that can be solved with PREEMPT_RT.

Well, yes, it is. What you are referring to is what I have been referring to when I say that the realtime patches have been mainlined into the generic kernel, and now you can use kernel boot time parameters to have this functionality. Linux kernel 6.12 was when that was mainlined. Unless we aren't understanding each other, we are in fact talking about the same thing.

If not, please explain again, and I will try again to understand what you are meaning. But I really do think we are talking about the exact same thing. I had been waiting for 20 years for this to happen, and it was integrated in Linux kernel 6.12. This functionality allows you to set the /preempt=full and /threadirqs functionality that makes the generic kernel at run time use the preempt_rt functionality inside the generic kernel. The only real difference that matters with a low latency kernel vs the generic kernel since 6.12 is that one is compiled, and the other is enabled with kernel boot parameters.

So, when you talk about "lack of specific testing makes it impossible to figure whether the normal preemption models have a problem that can be solved with preempt_rt", the normal preemption models since kernel 6.12 ARE the Preempt_rt models. Does that make sense?

Again, if we are miscommunicating, let me know. But I'm quite convinced that we are both talking about the same thing, but you might not have been aware that the "normal preemptive models" are now the PREEMPT_RT models--at least ever since kernel 6.12.

[ampetrosillo]

I suppose the real question is: how does the kernel respond with generic parameters? Do you really need to set full preemption and /threadirqs? 'cause unless they go out of their way to do that, the regular user won't do it. Just like I don't think you should need special kernels like Liquorix to get good performance. Maybe the special kernels give you *outstanding* performance but for most cases 10ms round trip latencies are mostly OK (like standing 3 meters away from the amp).

[audiojunkie]

I suppose the real question is: how does the kernel respond with generic parameters? Do you really need to set full preemption and /threadirqs? 'cause unless they go out of their way to do that, the regular user won't do it.

Well, yes, if you want to benefit from the preemption. But it's honestly much easier than building your own kernel, which is what needed to be done in the not too distant past (for distros that didn't provide their own realtime kernels). For those distros who do provide an actual compiled realtime kernel in their repositories, that can potentially be lower latency and more performant than using the normal low latency preemption which is what was introduced in kernel 6.12--but the difference isn't very much, and to me, not really worth the extra effort. Personally, I think that the work required to tell the package manager to download and install the realtime kernel is about the same effort that would be required to add the boot parameters.

Edit: When I say can potentially be lower latency and more performant, that's not the best way for me to put it. It's better to say that a realtime kernel is not necessarily lower latency, since they both are about the same (mostly). It's better to say that the Realtime kernel is more predictable. They can both perform nearly the same, but realtime has a guaranteed (or bounded) "worst-case" latency, and a deterministic scheduling. So while a correctly configured 6.12 kernel can achieve mostly the same latencies, the realtime kernel is guaranteed. I hope that makes sense.

[uOpt]

I suppose the real question is: how does the kernel respond with generic parameters? Do you really need to set full preemption and /threadirqs? 'cause unless they go out of their way to do that, the regular user won't do it. Just like I don't think you should need special kernels like Liquorix to get good performance. Maybe the special kernels give you *outstanding* performance but for most cases 10ms round trip latencies are mostly OK (like standing 3 meters away from the amp).

Well, nobody tested it.

Also keep in mind that it is a tradeoff between latency and throughput. The kernel configs with realtime will have substantially less simultaneous tracks in the usual "how many tracks can this machine feed at once?" style of tests. For an unknown benefit for latency.

[uOpt]

This exact options have become very confusing. They dropped one preemption model lately, so they are back down to 4. But they had "full preemption" before the RT merge, and now it is RT. I am just looking at the 7.0.0 kernel and it has 4 options for kernel start, but only 2 for compile time.

Might have to look at the code.

[audiojunkie]

I suppose the real question is: how does the kernel respond with generic parameters? Do you really need to set full preemption and /threadirqs? 'cause unless they go out of their way to do that, the regular user won't do it. Just like I don't think you should need special kernels like Liquorix to get good performance. Maybe the special kernels give you *outstanding* performance but for most cases 10ms round trip latencies are mostly OK (like standing 3 meters away from the amp).

Well, nobody tested it.

Also keep in mind that it is a tradeoff between latency and throughput. The kernel configs with realtime will have substantially less simultaneous tracks in the usual "how many tracks can this machine feed at once?" style of tests. For an unknown benefit for latency.

I'm not sure where you are getting your information? Yes, it is a tradeoff between latency and throughput, but that's the same whether you use a compiled realtime kernel, a compiled low latency kernel, or a generic kernel with kernel parameters. Think of it as a scale balance--when one goes up, the other goes down. The CPU and other components are the same no matter what is done with them. They all have their maximum processing capabilities. You get to choose what you prefer performance or throughput. When one goes up, the other goes down--and vice versa. They are tied to each other like a scale balance. That's just plain physics.

Lots of people have tested and reported their findings on LinuxMusicians.com. Go do a forum search to see what others report. Remember however, equipment matters a lot--not just what hardware specs, but also audio interface specs.

[lunardigs]

Pipewire has been improved significantly within the past 18 months or so.
Specifically, it got:
Multi-Threaded Execution support (overall performance boost)
New Bluetooth codecs (higher quality sound, e.g. A2DP, LDAC, AptX)
Improved A/V stream handling (many fixes and improvements)
Version 1.4 brought native MIDI 2.0 support and FFMPEG+Vulkan video processing support ...
Lots of good strides.

Personally, I think Pipewire is the biggest improvement to Linux audio we've yet seen.
Second to this, albeit unintentional perhaps, Apple with all their clout having pushed Class Compliant USB.
Outside of Linux systems specifically though, I think it's got to be JUCE that's brought some of the biggest improvement in terms of new plugins becoming available.

[uOpt]

I'm not sure where you are getting your information? Yes, it is a tradeoff between latency and throughput, but that's the same whether you use a compiled realtime kernel, a compiled low latency kernel, or a generic kernel with kernel parameters. Think of it as a scale balance--when one goes up, the other goes down. The CPU and other components are the same no matter what is done with them. They all have their maximum processing capabilities. You get to choose what you prefer performance or throughput. When one goes up, the other goes down--and vice versa. They are tied to each other like a scale balance. That's just plain physics.

Lots of people have tested and reported their findings on LinuxMusicians.com. Go do a forum search to see what others report. Remember however, equipment matters a lot--not just what hardware specs, but also audio interface specs.

Preemption is very expensive, computationally. You throw away more and more CPU cycles as you go up in aggressive preemption. When 6.12 came out I tested all the preemption models with kernel compilation benchmarks, and as expected PREEMPT_NONE had a noticeable speed advantage, with kernels getting slower and slower as preemption went up, with RT as expected losing out. And as I said, the NVidia drivers did not work with RT, so that was a dud.

If somebody tests "how many tracks does it run" then RT will lose.

[audiojunkie]

I'm not sure where you are getting your information? Yes, it is a tradeoff between latency and throughput, but that's the same whether you use a compiled realtime kernel, a compiled low latency kernel, or a generic kernel with kernel parameters. Think of it as a scale balance--when one goes up, the other goes down. The CPU and other components are the same no matter what is done with them. They all have their maximum processing capabilities. You get to choose what you prefer performance or throughput. When one goes up, the other goes down--and vice versa. They are tied to each other like a scale balance. That's just plain physics.

Lots of people have tested and reported their findings on LinuxMusicians.com. Go do a forum search to see what others report. Remember however, equipment matters a lot--not just what hardware specs, but also audio interface specs.

Preemption is very expensive, computationally. You throw away more and more CPU cycles as you go up in aggressive preemption. When 6.12 came out I tested all the preemption models with kernel compilation benchmarks, and as expected PREEMPT_NONE had a noticeable speed advantage, with kernels getting slower and slower as preemption went up, with RT as expected losing out. And as I said, the NVidia drivers did not work with RT, so that was a dud.

If somebody tests "how many tracks does it run" then RT will lose.

I don't disagree with you at all. Preemption is expensive computationally. The point that I'm making, is that it is physics. It affects every OS ever made and likely ever will be made. It doesn't matter what kernel you use. But you won't be able to get increased throughput AND Low Latency audio improved at the same time (exception being inefficiencies that are removed), because where throughput improves, latency gets worse. Vice versa, where Latency improves, throughput gets worse.

[ampetrosillo]

My point is, if setting the low latency flag allows you to go down from 7ms round-trip to 5ms on a USB interface, and if latency is *that* important to you, then probably a PCI-E audio interface is warranted, because that kind of latency is even easier to achieve and with more stability. But if the generic kernel already manages 7ms round-trip latency, basically on par with the other OSes, then I would say that it is at least fine. It can be made to get better latency if you really want to because on Linux you can fiddle with kernels, but it's not necessary?

[audiojunkie]

My point is, if setting the low latency flag allows you to go down from 7ms round-trip to 5ms on a USB interface, and if latency is *that* important to you, then probably a PCI-E audio interface is warranted, because that kind of latency is even easier to achieve and with more stability. But if the generic kernel already manages 7ms round-trip latency, basically on par with the other OSes, then I would say that it is at least fine. It can be made to get better latency if you really want to because on Linux you can fiddle with kernels, but it's not necessary?

I’m not sure if you are referring to me or uOpt, but I personally see things as you do and agree with you.

[mabian]

Well, the question was if there was progress lately with Linux and audio. For me the answer is definitely yes. I'm on Linux since end of 2024. Since then, I've seen tone boosters and kazrog get Linux native, obxf from surge adding to surge xt, short circuit xt being developed for Linux from the beginning, audiomodern getting to Linux.
New Devs like blepfx and tilr delivering amazing free stuff.
And, you all seem to forget that uhe is now providing the mighty zebra 3. Are we on the same level as windows and Mac? No, but that wasn't the initial question right?

Btw I'm also using wine and yabridge and I'm able to use dozens of windows plugins seamlessly embedded in Linux reaper. Not to mention audiogridder that further extends possibilities...I think there's never been a greater time to be making music on Linux. Microsoft helped quite a lot too

[uOpt]

My point is, if setting the low latency flag allows you to go down from 7ms round-trip to 5ms on a USB interface, and if latency is *that* important to you, then probably a PCI-E audio interface is warranted, because that kind of latency is even easier to achieve and with more stability. But if the generic kernel already manages 7ms round-trip latency, basically on par with the other OSes, then I would say that it is at least fine. It can be made to get better latency if you really want to because on Linux you can fiddle with kernels, but it's not necessary?

I’m not sure if you are referring to me or uOpt, but I personally see things as you do and agree with you.

Same here.

[karumba]

Just wanted to mention that the OD public beta is finished and native OD plugins for Linux are now available: https://linux.ohlhorstdigital.com/

Fabien & Vlad from TDR are also working on native Linux builds - won't be long now.